From stpeter@stpeter.im Tue Apr 6 13:29:04 2010 Return-Path: X-Original-To: urn@core3.amsl.com Delivered-To: urn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C0803A696C; Tue, 6 Apr 2010 13:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.023 X-Spam-Level: X-Spam-Status: No, score=-2.023 tagged_above=-999 required=5 tests=[AWL=0.576, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9v0m2MQrbJZ6; Tue, 6 Apr 2010 13:29:03 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 1EB793A6A3B; Tue, 6 Apr 2010 13:25:41 -0700 (PDT) Received: from dhcp-64-101-72-158.cisco.com (dhcp-64-101-72-158.cisco.com [64.101.72.158]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 38CCD40E15; Tue, 6 Apr 2010 14:25:38 -0600 (MDT) Message-ID: <4BBB98C0.5080600@stpeter.im> Date: Tue, 06 Apr 2010 14:25:36 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: IETF discussion list X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090304020208020100090602" Cc: urn-nid@ietf.org, uri@w3.org, urn@ietf.org, uri-review@ietf.org, "apps-discuss@ietf.org" Subject: [urn] new URN discussion list X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 20:29:04 -0000 This is a cryptographically signed message in MIME format. --------------ms090304020208020100090602 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable As a venue for discussion about possible revisions to the definition of Uniform Resource Names (URNs), the IETF Applications Area has created a new email list urn@ietf.org, to which you can subscribe as follows: https://www.ietf.org/mailman/listinfo/urn mailto:urn-request@ietf.org?body=3Dsubscribe Please note that the urn@ietf.org list is for discussion regarding the definition of URNs. We shall continue to use the urn-nid@ietf.org list for review of Namespace Identifiers (NIDs). Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms090304020208020100090602 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDQwNjIwMjUzNlowIwYJKoZIhvcNAQkEMRYEFOrsKSgQdcN/hRIEq50Z ayF8Ub+WMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAhvdmScRCwtIAhn6PbAmnSURWRTNnc0pBgMurrwga MULdOhko8n1mLmnL+yTWblRlKFQJK2gBUdWLKU3zMUrLEpU4jPFUcfOP/a9EX08theD86p2f vuup5Sx0LaFwLUn6hp8ZR7I3ruG7blloC9lE9+GYdX0v5d4sf8nirzju1bcDA2lkN5SZpHYZ B4KiM+4FKjHtPoOsXCUWpc7JSRrOt8DHQvFh05Px/y07131mHb+ri8bNO/ureUI7eLat3lAC Bt9GhmJ9N38WE8IzCUyPuX8O9M+uzoURSqTr72tZEhCYhN2/oMNUfe5E+eQlbC6lnXO0Qf8k YP7cNcf5+60k3wAAAAAAAA== --------------ms090304020208020100090602-- From A.Hoenes@TR-Sys.de Thu Apr 22 01:36:57 2010 Return-Path: X-Original-To: urn@core3.amsl.com Delivered-To: urn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EC403A688D; Thu, 22 Apr 2010 01:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.076 X-Spam-Level: X-Spam-Status: No, score=-96.076 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WMDrVzkTPkr; Thu, 22 Apr 2010 01:36:56 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 975143A6813; Thu, 22 Apr 2010 01:36:54 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA239065367; Thu, 22 Apr 2010 10:36:07 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id KAA03118; Thu, 22 Apr 2010 10:36:06 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201004220836.KAA03118@TR-Sys.de> To: apps-discuss@ietf.org, uri-review@ietf.org, urn-nid@ietf.org, uri@w3.org Date: Thu, 22 Apr 2010 10:36:05 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Cc: urn@ietf.org Subject: Re: [urn] new URN discussion list X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 08:36:57 -0000 [[ apologies for cross-posting once more; please direct follow-up messages to urn@ietf.org -- thanks! ]] At Tue, 06 Apr 2010 14:25:36 -0600, Peter Saint-Andre wrote: > As a venue for discussion about possible revisions to the definition of > Uniform Resource Names (URNs), the IETF Applications Area has created a > new email list urn at ietf.org, to which you can subscribe as follows: > > https://www.ietf.org/mailman/listinfo/urn > > mailto:urn-request at ietf.org?body=subscribe > > Please note that the urn at ietf.org list is for discussion > regarding the definition of URNs. We shall continue to use the > urn-nid at ietf.org list for review of Namespace Identifiers (NIDs). Please note that, accordingly, discussion now should happen on urn@ietf.org regarding: - the draft charter for a "URNbis" WG (target: BoF at IETF 78) (first draft to be submitted soon) and - the following Internet-Drafts: o draft-ah-rfc2141bis-urn (updated definition of the 'URN' URI Scheme, revision of RFC 2141 -- the -01 draft version will point to the new list), o draft-hakala-rfc3187bis-isbn-urn (revised URN namespace definition for 'ISBN' including ISNB-13 -- the -01 draft version will point to the new list), o draft-hakala-rfc3188bis-nbn-urn (revised URN namespace definition for 'NBN', -00 version to be submitted soon). The appropriate functional lists (uri-review and urn-nid) will be consulted again as soon as the process has advanced enough, according to RFC 4395 (BCP 35) and RFC 3406 (BCP 66), respectively. Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From A.Hoenes@TR-Sys.de Tue Apr 27 10:06:01 2010 Return-Path: X-Original-To: urn@core3.amsl.com Delivered-To: urn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5D653A6A1C for ; Tue, 27 Apr 2010 10:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.624 X-Spam-Level: X-Spam-Status: No, score=-95.624 tagged_above=-999 required=5 tests=[AWL=-0.389, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, SARE_MILLIONSOF=0.315, 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 jevW9gOtmJ39 for ; Tue, 27 Apr 2010 10:06:00 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 3B3DA3A68A2 for ; Tue, 27 Apr 2010 10:05:58 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA267597908; Tue, 27 Apr 2010 19:05:08 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id TAA10987 for urn@ietf.org; Tue, 27 Apr 2010 19:05:07 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201004271705.TAA10987@TR-Sys.de> To: urn@ietf.org Date: Tue, 27 Apr 2010 19:05:07 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Subject: [urn] A first cut at the Draft Charter for the proposed URNbis WG X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 17:06:02 -0000 Folks, Based on work done by Juha Hakala in February, I have updated and amended the Draft Charter and hereby bring it to the urn list for discussion. Comments welcome! Kind regards, Alfred HÎnes. ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- Uniform Resource Names, Revised (URNbis) -- Draft Proposed WG Charter ======================================== Last Modified: 2010-04-26 [AH] Chair(s): o Juha Hakala o N.N. Applications Area Director(s): o Alexey Melnikov o Peter Saint-Andre Applications Area Advisor: o Peter Saint-Andre Mailing Lists: General Discussion: urn@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/urn Archive: http://www.ietf.org/mail-archive/web/urn/current/maillist.html Related lists (used for IANA registration procedures (BCP 35/66): urn-nid@ietf.org, uri-review@ietf.org Additional information will be available at: http://tools.ietf.org/wg/urnbis Description of Working Group: Uniform Resource Names (URNs) are persistent identifiers for information resources. The RFCs defining URNs and services based on them were published 1997-2001. Since then, the URN system has gained popularity. Among the more traditional parties with deep interest in persistent identifiers and making heavy use of URNs are national libraries; solely within this area, tens of millions of resources have been assigned URNs; this enables efficient searching of and persistent linking to these documents. This working group is chartered to revise the key RFCs describing the URN system, including RFC 2141 (URN Syntax) and RFC 4306 (Namespace Definition Mechanisms), update important URN namespace specifications, and to screen and update RFCs describing URN resolution principles and practices. For RFC 2141, this revision will include in particular: an update of the formal syntax specification in the light of the URI Standard (STD 66, RFC 3986) using the ABNF from STD 68 (RFC 5234), a revision of URN examples from imaginary ones into existing URNs in current namespaces, providing a formal IANA registration for the 'urn' URI scheme using the template from BCP 35 (RFC 4395), and an update of the section describing how URNs are resolved in the Internet. RFC 4306 (BCP 66) needs a less pervasive update, mostly to align it with the current IANA procedures and terminology as defined in BCP 26 (RFC 5226). Regarding URN Namespace specifications, the WG will focus on updates for the definitions of URNs based on bibliographic identifier systems, in particular RFC 3187 (URN Namespace for International Standard Book Numbers) and RFC 3188 (URN Namespace for National Bibliography Numbers). In both cases, the respective identifier system and/or the institutions and roles involved in their assignment and resolution have evolved significantly since these RFCs have been published. In particular, the URN:ISBN namespace needs to be extended according to the revision of the international ISBN standard, and the usage of the URN:NBNs has grown rapidly and there is a need to align the namespace registration with experience and current practice. In a second stage, RFC 3044 (URN Namespace for International Series Standard Number) will be checked for the necessity of an update. Thus, in support of the current international efforts to establish a distributed, linked system of URN resolution systems for bibliographic identifiers, the primary aim of the WG is an updated set of standards documents, which is needed to assure uniformity and interoperability of the URN resolution services. Alongside the modernization of these core RFCs for URNs and specific URN namespaces, the working group will also consider a revision of earlier RFCs related to the principles of URNs and URN resolution, such as RFC 2483 (URI Resolution services necessary for URN resolution), RFC 2276 (Architectural principles of Uniform Resource Name Resolution), RFC 1737 (Functional requirements for Uniform Resource Names) and RFC 2169 (A trivial convention for using HTTP in URN resolution). All these must be checked; if the document is still deemed relevant, it will be modernized. The working group will also consider the possibility of publishing Best Current Practices on how to resolve the URNs utilizing the existing Internet protocols such as HTTP. This BCP will be based on the European URN resolution infrastructure under construction in the project PersID. Since the revised specifications will be based on existing production systems and provide important guidelines for future implementers, the WG aims at publishing the RFCs on the Standards Track and will try to advance the core document at least to Draft Standard status as fast as possible. The WG can take on work to update other well-established URN namespace definitions upon a case-by-case decision. Input documents: RFC 2141 RFC 3406 RFC 3187 RFC 3188 RFC 2483 RFC 2276 RFC 1737 RFC 2169 Goals and Milestones (preliminary): Feb 2010 Initial WG formation as 'URN-R' (outside the IETF) Mar 2010 WG work plan completed, brought to IETF APP Area May 2010 first Internet-Drafts for most important core document revisions Jul 2010 Presentation of the group & early results at IETF 78 (BoF) Aug 2010 Formal establishment of the IETF WG Dec 2010 WG Last Call on WG core document set Feb 2011 core document set forwarded to IESG 2011 work on supporting documents (guidelines, URN resolution) 2012 implementation report for promoting 2141bis to Draft Std. Internet-Drafts: draft-ah-rfc2141bis-urn (-00: March 2010) draft-hakala-rfc3187bis-isbn-urn (-00: March 2010) draft-hakala-rfc3188bis-nbn-urn (-00 due for week 18/2010) Request For Comments: none so far From juha.hakala@helsinki.fi Tue Apr 27 22:23:44 2010 Return-Path: X-Original-To: urn@core3.amsl.com Delivered-To: urn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BD2E3A6ADF for ; Tue, 27 Apr 2010 22:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.784 X-Spam-Level: X-Spam-Status: No, score=-2.784 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EVs1AWUcI5cZ for ; Tue, 27 Apr 2010 22:22:57 -0700 (PDT) Received: from kill.it.helsinki.fi (kill.it.helsinki.fi [128.214.205.47]) by core3.amsl.com (Postfix) with ESMTP id 4A9AD3A6A45 for ; Tue, 27 Apr 2010 22:21:13 -0700 (PDT) Received: from kill.it.helsinki.fi (kill.it.helsinki.fi [128.214.205.47]) by kill.it.helsinki.fi (8.13.1/8.13.1) with ESMTP id o3S5KtAR000434; Wed, 28 Apr 2010 08:20:56 +0300 Received: from [128.214.91.90] (kkkl25.lib.helsinki.fi [128.214.91.90]) by smtp-rs2.it.helsinki.fi (8.13.8/8.13.8) with ESMTP id o3S5Ktjb029911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Apr 2010 08:20:55 +0300 Message-ID: <4BD7C5B6.5060206@helsinki.fi> Date: Wed, 28 Apr 2010 08:20:54 +0300 From: Juha Hakala User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: =?UTF-8?B?QWxmcmVkIO+/vQ==?= References: <201004271705.TAA10987@TR-Sys.de> In-Reply-To: <201004271705.TAA10987@TR-Sys.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-HY-Tests: ALL_TRUSTED,SHORTCIRCUIT Cc: Maurizio Lunghi , "Cordewener, Bas" , urn@ietf.org, Roberto Puccinelli Subject: Re: [urn] A first cut at the Draft Charter for the proposed URNbis WG X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 05:23:44 -0000 Hello all, Quite a lot has already happened since February, so the draft charter written by me back then was already badly out of date. Alfred's thorough revision has updated the charter, and also improved its content significantly in other ways. I have only two requests for changes. This sentence: > In a second stage, RFC 3044 (URN Namespace for International Series > Standard Number) will be checked for the necessity of an update. Should be changed into: "The need for revising RFC 3044 (URN Namespace registration for ISSN, International Serial Standard Number) will be analysed with the ISSN International Centre. If the revision is required, it will be done in close co-operation with the centre." I have discussed revision of RFC 3044 with the ISSN International Centre, but no firm decision has been done yet to start the work. The second request is that RFC 3044 should be added to the list of input documents, before RFC 3187 so that all namespace registrations are grouped together. RFC3188bis still needs a lot of work. PersID colleagues and Alfred have provided many useful comments to the preliminary draft that will / must be taken into account, but my intention is still to publish the first draft on week 18 as the attached version of the charter suggests (that is, the deadline is Friday 7th of May). Best regards, Juha Alfred � wrote: > Folks, > Based on work done by Juha Hakala in February, I have updated > and amended the Draft Charter and hereby bring it to the urn list > for discussion. Comments welcome! > > Kind regards, > Alfred H�nes. > > > ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- > > Uniform Resource Names, Revised (URNbis) -- Draft Proposed WG Charter > ======================================== > > Last Modified: 2010-04-26 [AH] > > Chair(s): > o Juha Hakala > o N.N. > > Applications Area Director(s): > o Alexey Melnikov > o Peter Saint-Andre > > Applications Area Advisor: > o Peter Saint-Andre > > Mailing Lists: > General Discussion: urn@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/urn > Archive: http://www.ietf.org/mail-archive/web/urn/current/maillist.html > > Related lists (used for IANA registration procedures (BCP 35/66): > urn-nid@ietf.org, uri-review@ietf.org > > Additional information will be available at: > http://tools.ietf.org/wg/urnbis > > Description of Working Group: > > Uniform Resource Names (URNs) are persistent identifiers for > information resources. The RFCs defining URNs and services based on > them were published 1997-2001. Since then, the URN system has gained > popularity. Among the more traditional parties with deep interest in > persistent identifiers and making heavy use of URNs are national > libraries; solely within this area, tens of millions of resources > have been assigned URNs; this enables efficient searching of and > persistent linking to these documents. > > This working group is chartered to revise the key RFCs describing the > URN system, including RFC 2141 (URN Syntax) and RFC 4306 (Namespace > Definition Mechanisms), update important URN namespace specifications, > and to screen and update RFCs describing URN resolution principles > and practices. > > For RFC 2141, this revision will include in particular: an update of > the formal syntax specification in the light of the URI Standard > (STD 66, RFC 3986) using the ABNF from STD 68 (RFC 5234), a revision > of URN examples from imaginary ones into existing URNs in current > namespaces, providing a formal IANA registration for the 'urn' URI > scheme using the template from BCP 35 (RFC 4395), and an update of > the section describing how URNs are resolved in the Internet. > RFC 4306 (BCP 66) needs a less pervasive update, mostly to align it > with the current IANA procedures and terminology as defined in BCP 26 > (RFC 5226). > > Regarding URN Namespace specifications, the WG will focus on updates > for the definitions of URNs based on bibliographic identifier systems, > in particular RFC 3187 (URN Namespace for International Standard Book > Numbers) and RFC 3188 (URN Namespace for National Bibliography > Numbers). In both cases, the respective identifier system and/or the > institutions and roles involved in their assignment and resolution > have evolved significantly since these RFCs have been published. > In particular, the URN:ISBN namespace needs to be extended according > to the revision of the international ISBN standard, and the usage of > the URN:NBNs has grown rapidly and there is a need to align the > namespace registration with experience and current practice. > In a second stage, RFC 3044 (URN Namespace for International Series > Standard Number) will be checked for the necessity of an update. > > Thus, in support of the current international efforts to establish a > distributed, linked system of URN resolution systems for bibliographic > identifiers, the primary aim of the WG is an updated set of standards > documents, which is needed to assure uniformity and interoperability > of the URN resolution services. > > Alongside the modernization of these core RFCs for URNs and specific > URN namespaces, the working group will also consider a revision of > earlier RFCs related to the principles of URNs and URN resolution, > such as RFC 2483 (URI Resolution services necessary for URN > resolution), RFC 2276 (Architectural principles of Uniform Resource > Name Resolution), RFC 1737 (Functional requirements for Uniform > Resource Names) and RFC 2169 (A trivial convention for using HTTP in > URN resolution). All these must be checked; if the document is still > deemed relevant, it will be modernized. > > The working group will also consider the possibility of publishing > Best Current Practices on how to resolve the URNs utilizing the > existing Internet protocols such as HTTP. This BCP will be based on > the European URN resolution infrastructure under construction in the > project PersID. > > Since the revised specifications will be based on existing production > systems and provide important guidelines for future implementers, > the WG aims at publishing the RFCs on the Standards Track and will try > to advance the core document at least to Draft Standard status as fast > as possible. > > The WG can take on work to update other well-established URN namespace > definitions upon a case-by-case decision. > > > Input documents: > > RFC 2141 > RFC 3406 > > RFC 3187 > RFC 3188 > > RFC 2483 > RFC 2276 > RFC 1737 > RFC 2169 > > Goals and Milestones (preliminary): > > Feb 2010 Initial WG formation as 'URN-R' (outside the IETF) > Mar 2010 WG work plan completed, brought to IETF APP Area > May 2010 first Internet-Drafts for most important core document > revisions > Jul 2010 Presentation of the group & early results at IETF 78 (BoF) > Aug 2010 Formal establishment of the IETF WG > Dec 2010 WG Last Call on WG core document set > Feb 2011 core document set forwarded to IESG > 2011 work on supporting documents (guidelines, URN resolution) > 2012 implementation report for promoting 2141bis to Draft Std. > > Internet-Drafts: > > draft-ah-rfc2141bis-urn (-00: March 2010) > draft-hakala-rfc3187bis-isbn-urn (-00: March 2010) > draft-hakala-rfc3188bis-nbn-urn (-00 due for week 18/2010) > > Request For Comments: > > none so far > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn -- Juha Hakala Director of IT Development The National Library of Finland P.O.Box 15 (Unioninkatu 36, room 503), FIN-00014 Helsinki University Email juha.hakala@helsinki.fi, tel +358 50 382 7678 From moore@network-heretics.com Tue Apr 27 23:49:57 2010 Return-Path: X-Original-To: urn@core3.amsl.com Delivered-To: urn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 659D13A6883 for ; Tue, 27 Apr 2010 23:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0o8PMy6498YV for ; Tue, 27 Apr 2010 23:49:56 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id BD5083A6846 for ; Tue, 27 Apr 2010 23:49:56 -0700 (PDT) Received: from lust.indecency.org (174-151-122-31.pools.spcsdns.net [174.151.122.31]) by m1.imap-partners.net (MOS 4.1.8-GA) with ESMTP id BQX42218 (AUTH admin@network-heretics.com); Tue, 27 Apr 2010 23:49:37 -0700 X-Mirapoint-Received-SPF: 174.151.122.31 lust.indecency.org 5 none X-Mirapoint-Received-SPF: 174.151.122.31 lust.indecency.org 5 none X-Mirapoint-Received-SPF: 174.151.122.31 lust.indecency.org 5 none Message-ID: <4BD7DA80.8080101@network-heretics.com> Date: Wed, 28 Apr 2010 02:49:36 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: =?UTF-8?B?QWxmcmVkIO+/vQ==?= References: <201004271705.TAA10987@TR-Sys.de> In-Reply-To: <201004271705.TAA10987@TR-Sys.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] A first cut at the Draft Charter for the proposed URNbis WG X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 06:49:57 -0000 I'm a bit curious and I can't really tell from the charter - what is it about the URN syntax that needs to be changed? I feel like RFC 2141 is sort of a contract with implementors to say "this is what URNs will look like" and we have an obligation to not change it without a very good reason. I don't suppose it hurts too much to change to the newer style ABNF notation as long as the new ABNF recognizes the same set of strings as the old ABNF, but I don't think that "new ABNF" is a sufficiently good reason by itself. And I haven't analyzed RFC 2141 against RFC 3986 to see how the latter might be incompatible with the former. But in my opinion, if there is any incompatibility, it's latter document which is incorrect. I don't think RFC 3986 was meant to retroactively invalidate existing practice. As the entire idea behind URNs is for them to be long-term persistent identifiers, I think it's especially important that IETF not invalidate existing URNs or use of URNs, as long as such URNs were created and such use is consistent with existing IETF standards. Keith From A.Hoenes@TR-Sys.de Wed Apr 28 00:13:49 2010 Return-Path: X-Original-To: urn@core3.amsl.com Delivered-To: urn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 514123A688F for ; Wed, 28 Apr 2010 00:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.058 X-Spam-Level: X-Spam-Status: No, score=-96.058 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qah5fZmmGT01 for ; Wed, 28 Apr 2010 00:13:48 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 36EA23A6AAB for ; Wed, 28 Apr 2010 00:13:45 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA271608775; Wed, 28 Apr 2010 09:12:55 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id JAA11679; Wed, 28 Apr 2010 09:12:54 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201004280712.JAA11679@TR-Sys.de> To: juha.hakala@helsinki.fi Date: Wed, 28 Apr 2010 09:12:54 +0200 (MESZ) In-Reply-To: <4BD7C5B6.5060206@helsinki.fi> from Juha Hakala at Apr "28, " 2010 "08:20:54" am X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] A first cut at the Draft Charter for the proposed URNbis WG X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 07:13:49 -0000 Juha, thanks for your response. > Hello all, > > Quite a lot has already happened since February, so the draft charter > written by me back then was already badly out of date. Alfred's thorough > revision has updated the charter, and also improved its content > significantly in other ways. > > I have only two requests for changes. This sentence: > >> In a second stage, RFC 3044 (URN Namespace for International Series >> Standard Number) will be checked for the necessity of an update. > > Should be changed into: > > "The need for revising RFC 3044 (URN Namespace registration for ISSN, > International Serial Standard Number) will be analysed with the ISSN > International Centre. If the revision is required, it will be done in > close co-operation with the centre." Unless someone opposes and takes over the duty, I'll maintain a working copy of the draft charter, incorporate changes as they are suggested and accepted, and re-post it to the list as approporiate, until a BoF Wiki has been granted and it can be maintained there directly. Of course, your above change is "accepted"! I thought adding RFC 3044 to the text from the first cut on would be prudent, and I expected feedback from you to this topic. > I have discussed revision of RFC 3044 with the ISSN International > Centre, but no firm decision has been done yet to start the work. > > The second request is that RFC 3044 should be added to the list of input > documents, before RFC 3187 so that all namespace registrations are > grouped together. I agree -- I'd better included it in the list immediately; but since the list somehow reflects the 'precedence' of work (already done or in progress, or still to be started), which also is the order in which these RFCs are discussed in the body of the charter text, I'd prefer to list it _after_ 3187 and 3188. > RFC3188bis still needs a lot of work. PersID colleagues and Alfred have > provided many useful comments to the preliminary draft that will / must > be taken into account, but my intention is still to publish the first > draft on week 18 as the attached version of the charter suggests (that > is, the deadline is Friday 7th of May). > > Best regards, > > Juha > > Alfred wrote: >> Folks, >> Based on work done by Juha Hakala in February, I have updated >> and amended the Draft Charter and hereby bring it to the urn list >> for discussion. Comments welcome! >> >> (see: ) > > -- > > Juha Hakala > Director of IT Development > > The National Library of Finland > P.O.Box 15 (Unioninkatu 36, room 503), FIN-00014 Helsinki University > Email juha.hakala@helsinki.fi, tel +358 50 382 7678 Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From A.Hoenes@TR-Sys.de Wed Apr 28 01:03:18 2010 Return-Path: X-Original-To: urn@core3.amsl.com Delivered-To: urn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 102D13A6855 for ; Wed, 28 Apr 2010 01:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.063 X-Spam-Level: X-Spam-Status: No, score=-96.063 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7tIyTsSJ3rq for ; Wed, 28 Apr 2010 01:03:17 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id DDDA43A6888 for ; Wed, 28 Apr 2010 01:03:15 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA271791745; Wed, 28 Apr 2010 10:02:25 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id KAA11778; Wed, 28 Apr 2010 10:02:23 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201004280802.KAA11778@TR-Sys.de> To: moore@network-heretics.com Date: Wed, 28 Apr 2010 10:02:23 +0200 (MESZ) In-Reply-To: <4BD7DA80.8080101@network-heretics.com> from Keith Moore at Apr "28, " 2010 "02:49:36" am X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] rfc2141bis [was: Re: A first cut at the Draft Charter ...] X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 08:03:18 -0000 Keith, thanks for your feedback. > I'm a bit curious and I can't really tell from the charter - what is it > about the URN syntax that needs to be changed? I feel like RFC 2141 is > sort of a contract with implementors to say "this is what URNs will look > like" and we have an obligation to not change it without a very good > reason. I don't suppose it hurts too much to change to the newer style > ABNF notation as long as the new ABNF recognizes the same set of strings > as the old ABNF, but I don't think that "new ABNF" is a sufficiently > good reason by itself. And I haven't analyzed RFC 2141 against RFC 3986 > to see how the latter might be incompatible with the former. But in my > opinion, if there is any incompatibility, it's latter document which is > incorrect. I don't think RFC 3986 was meant to retroactively invalidate > existing practice. > > As the entire idea behind URNs is for them to be long-term persistent > identifiers, I think it's especially important that IETF not invalidate > existing URNs or use of URNs, as long as such URNs were created and such > use is consistent with existing IETF standards. > > Keith You're knocking on open doors! (see below) Since the details are already described in the rfc2141bis draft, the draft charter has been kept rather terse in this regard. It would be great if you could review the draft (or at least the syntax part, for now) and check your concerns with the draft text. The primary issues I found in RFC 2141 were the contradictions between the formal BNF and the textual description -- the syntax rules admitted specific delimiter characters that subsequently got waived in the prose, and the formal rules were ambiguous regarding the '%' character. I have tried to document these details and the envisioned changes in the original draft published end of March and my announcement sent to the uri-review, apps-discuss, and urn-nid lists (AT IETF.ORG) -- please refer to the draft's announcement archived at and to the draft proper, available at . Further, the draft tries to make clear the relationship of URN syntax to the RFC 3986 URI components and syntax rules and re-use them where possible, to the benefit of parser implementers. Admittedly, the text and formatting in the syntax section got a bit unpleasant by the attempt to present new text and juxtapose referenced text and discussion; that will be cleaned up after resolution, and a detailed change log (both incrementally and from RFC 2141 to the draft) be added in the next draft revisions. Regarding the principles: Of course, no existing URN namespace definition or URN instance must be invalidated by the revised specification. The primary questions are related to whether or not the general URN syntax should allow *new* or *revised* URN namespace definitions to explicitly admit and/or parts, and whether or not the few delimiter characters admitted in the revised URI syntax components but not in RFC 2141 should be allowed (without percent-encoding) in the URN syntax. It has been reported to me that for URNs based on bibliographic identifiers, some folks would like to be able to add a fragment identifier, which could be carried over unchanged into a network reachable URI (e.g. http URI) returned by a URN resolution service given such extenedd, say NBN, URN. I have not heard of a similar use case for parts, so this is more or less a theoretical question so far, but it should be assessed as well in the WG. Leslie Daigle has reported that these questions have been discussed controversially in the original URN WG, and we hope that the list archives from those days (that unfortunately have disappeared from the public web) can be restored on the servers maintained by the IETF Secretariat, in order to make that precedent available to all. It will be part of the WG's task to cross check with all existing URN namespace definitions the impact of what goes into rfc2141bis. Kind regards, Alfred. From julian.reschke@gmx.de Wed Apr 28 05:56:37 2010 Return-Path: X-Original-To: urn@core3.amsl.com Delivered-To: urn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B74028C0DF for ; Wed, 28 Apr 2010 05:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.163 X-Spam-Level: X-Spam-Status: No, score=-3.163 tagged_above=-999 required=5 tests=[AWL=-3.464, BAYES_50=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KC29B0byuL4m for ; Wed, 28 Apr 2010 05:56:36 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 5C80D3A6BE5 for ; Wed, 28 Apr 2010 05:56:31 -0700 (PDT) Received: (qmail invoked by alias); 28 Apr 2010 12:56:18 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.116]) [217.91.35.233] by mail.gmx.net (mp020) with SMTP; 28 Apr 2010 14:56:18 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18cQrM/eSAcsl4pzazxRq1YBF6ku7jMpDhJhtnrrk JcnkUZ2LTBf29b Message-ID: <4BD83069.6060407@gmx.de> Date: Wed, 28 Apr 2010 14:56:09 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: =?UTF-8?B?QWxmcmVkIO+/vQ==?= References: <201004280802.KAA11778@TR-Sys.de> In-Reply-To: <201004280802.KAA11778@TR-Sys.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.56999999999999995 Cc: urn@ietf.org, moore@network-heretics.com Subject: [urn] fragment identifiers, Re: rfc2141bis [was: Re: A first cut at the Draft Charter ...] X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 12:56:37 -0000 On 28.04.2010 10:02, Alfred � wrote: > ... > The primary questions are related to whether or not the general URN > syntax should allow *new* or *revised* URN namespace definitions to > explicitly admit and/or parts, and whether or > not the few delimiter characters admitted in the revised URI syntax > components but not in RFC 2141 should be allowed (without > percent-encoding) in the URN syntax. > ... URNs are URIs, right? According to RFC 3986, the fragment identifier is entirely independent from the URI scheme: "The semantics of a fragment identifier are defined by the set of representations that might result from a retrieval action on the primary resource. The fragment's format and resolution is therefore dependent on the media type [RFC2046] of a potentially retrieved representation, even though such a retrieval is only performed if the URI is dereferenced. If no such representation exists, then the semantics of the fragment are considered unknown and are effectively unconstrained. Fragment identifier semantics are independent of the URI scheme and thus cannot be redefined by scheme specifications." -- So the question here is: what's the purpose of a fragment identifier in the absence of a representation? Best regards, Julian From moore@network-heretics.com Wed Apr 28 06:28:19 2010 Return-Path: X-Original-To: urn@core3.amsl.com Delivered-To: urn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FEB728C1D4 for ; Wed, 28 Apr 2010 06:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.452 X-Spam-Level: X-Spam-Status: No, score=0.452 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_38=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 Y+jWUMhMDhIX for ; Wed, 28 Apr 2010 06:28:18 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id BAFAA28C193 for ; Wed, 28 Apr 2010 06:23:49 -0700 (PDT) Received: from lust.indecency.org (174-151-122-31.pools.spcsdns.net [174.151.122.31]) by m1.imap-partners.net (MOS 4.1.8-GA) with ESMTP id BQY18072 (AUTH admin@network-heretics.com); Wed, 28 Apr 2010 06:23:28 -0700 X-Mirapoint-Received-SPF: 174.151.122.31 lust.indecency.org 5 none X-Mirapoint-Received-SPF: 174.151.122.31 lust.indecency.org 5 none X-Mirapoint-Received-SPF: 174.151.122.31 lust.indecency.org 5 none X-Mirapoint-Received-SPF: 174.151.122.31 lust.indecency.org 5 none Message-ID: <4BD836CF.1070402@network-heretics.com> Date: Wed, 28 Apr 2010 09:23:27 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Julian Reschke References: <201004280802.KAA11778@TR-Sys.de> <4BD83069.6060407@gmx.de> In-Reply-To: <4BD83069.6060407@gmx.de> Content-Type: multipart/alternative; boundary="------------050109000202010409040105" Cc: =?UTF-8?B?QWxmcmVkIO+/vQ==?= , urn@ietf.org Subject: Re: [urn] fragment identifiers, Re: rfc2141bis [was: Re: A first cut at the Draft Charter ...] X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 13:28:19 -0000 This is a multi-part message in MIME format. --------------050109000202010409040105 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 4/28/10 8:56 AM, Julian Reschke wrote: > On 28.04.2010 10:02, Alfred � wrote: >> ... >> The primary questions are related to whether or not the general URN >> syntax should allow *new* or *revised* URN namespace definitions to >> explicitly admit and/or parts, and whether or >> not the few delimiter characters admitted in the revised URI syntax >> components but not in RFC 2141 should be allowed (without >> percent-encoding) in the URN syntax. > > ... > > URNs are URIs, right? According to RFC 3986, the fragment identifier > is entirely independent from the URI scheme: Mumble. A single URI (including a URN) can map to multiple representations of a resource through content negotiation of some kind. But in practice, fragment identifiers don't readily map between one representation (typically content-type, though you can also have multiple representations with the same content-type) and another. What I find myself wondering is whether a URN with a fragment id has a persistent binding between the URN and the resource (fragment) that it identifies. I suppose that academically you could say that the URN->resource binding is still persistent even if the URN#fragment -> resource fragment binding is not persistent. But people tend to associate the fragment identifier with the URI, so I suspect that using a fragment id with a URN is at best confusing. We could write a rule that says "don't use fragment ids with a URN unless those fragment ids are meaningful across all representations of the resources named by the URN." But I keep seeing examples that illustrate that people don't understand URNs or how they're to be used, even though the rules are quite simple. I suspect that adding more rules decreases the likelihood that people will use URNs correctly. But neither do I want to revise 3986 to say that fragment ids don't apply to URNs. That's a huge can of worms I'd prefer to leave closed. So maybe writing the rule is the best way. Though I have little confidence that it will be followed. Keith --------------050109000202010409040105 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 4/28/10 8:56 AM, Julian Reschke wrote:
On 28.04.2010 10:02, Alfred � wrote:
...
The primary questions are related to whether or not the general URN
syntax should allow *new* or *revised* URN namespace definitions to
explicitly admit<question>  and/or<fragment>  parts, and whether or
not the few delimiter characters admitted in the revised URI syntax
<path>  components but not in RFC 2141 should be allowed (without
percent-encoding) in the URN syntax.
> ...

URNs are URIs, right? According to RFC 3986, the fragment identifier is entirely independent from the URI scheme:
Mumble. 

A single URI (including a URN) can map to multiple representations of a resource through content negotiation of some kind.  But in practice, fragment identifiers don't readily map between one representation (typically content-type, though you can also have multiple representations with the same content-type) and another.   What I find myself wondering is whether a URN with a fragment id has a persistent binding between the URN and the resource (fragment) that it identifies.  I suppose that academically you could say that the URN->resource binding is still persistent even if the URN#fragment -> resource fragment binding is not persistent.  But people tend to associate the fragment identifier with the URI, so I suspect that using a fragment id with a URN is at best confusing.

We could write a rule that says "don't use fragment ids with a URN unless those fragment ids are meaningful across all representations of the resources named by the URN."  But I keep seeing examples that illustrate that people don't understand URNs or how they're to be used, even though the rules are quite simple.   I suspect that adding more rules decreases the likelihood that people will use URNs correctly.

But neither do I want to revise 3986 to say that fragment ids don't apply to URNs.  That's a huge can of worms I'd prefer to leave closed.

So maybe writing the rule is the best way.   Though I have little confidence that it will be followed.

Keith
--------------050109000202010409040105-- From julian.reschke@gmx.de Wed Apr 28 06:37:41 2010 Return-Path: X-Original-To: urn@core3.amsl.com Delivered-To: urn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 127493A69B0 for ; Wed, 28 Apr 2010 06:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.617 X-Spam-Level: X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[AWL=-3.818, BAYES_50=0.001, J_CHICKENPOX_32=0.6, J_CHICKENPOX_38=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 mH3VtAIXJOsl for ; Wed, 28 Apr 2010 06:37:40 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 5779A28C102 for ; Wed, 28 Apr 2010 06:35:52 -0700 (PDT) Received: (qmail invoked by alias); 28 Apr 2010 13:35:39 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.116]) [217.91.35.233] by mail.gmx.net (mp038) with SMTP; 28 Apr 2010 15:35:39 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+9yUkexoG9uYdZBgaEodPexUlgdkYha+KjjGCscy H0zGu/QvxW5ibP Message-ID: <4BD839A3.4010404@gmx.de> Date: Wed, 28 Apr 2010 15:35:31 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Keith Moore References: <201004280802.KAA11778@TR-Sys.de> <4BD83069.6060407@gmx.de> <4BD836CF.1070402@network-heretics.com> In-Reply-To: <4BD836CF.1070402@network-heretics.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.56999999999999995 Cc: =?UTF-8?B?QWxmcmVkIO+/vQ==?= , urn@ietf.org Subject: Re: [urn] fragment identifiers, Re: rfc2141bis [was: Re: A first cut at the Draft Charter ...] X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 13:37:41 -0000 On 28.04.2010 15:23, Keith Moore wrote: > ... > Mumble. > > A single URI (including a URN) can map to multiple representations of a > resource through content negotiation of some kind. But in practice, > fragment identifiers don't readily map between one representation Sometimes they do... > (typically content-type, though you can also have multiple > representations with the same content-type) and another. What I find > myself wondering is whether a URN with a fragment id has a persistent > binding between the URN and the resource (fragment) that it identifies. > I suppose that academically you could say that the URN->resource binding > is still persistent even if the URN#fragment -> resource fragment > binding is not persistent. But people tend to associate the fragment > identifier with the URI, so I suspect that using a fragment id with a > URN is at best confusing. It is. > We could write a rule that says "don't use fragment ids with a URN > unless those fragment ids are meaningful across all representations of > the resources named by the URN." But I keep seeing examples that That would be almost the same rule as for any URL^HI. > illustrate that people don't understand URNs or how they're to be used, > even though the rules are quite simple. I suspect that adding more > rules decreases the likelihood that people will use URNs correctly. > > But neither do I want to revise 3986 to say that fragment ids don't > apply to URNs. That's a huge can of worms I'd prefer to leave closed. > > So maybe writing the rule is the best way. Though I have little > confidence that it will be followed. What we need to do is to clarify that although fragment identifiers aren't particularly useful unless you have representations, the URN *syntax* - being compatible to RFC 3986 - allows them; and thus the hash character needs to be percent-escaped in a URN. (which reminds me of ). Best regards, Julian From xiao@renci.org Wed Apr 28 06:44:06 2010 Return-Path: X-Original-To: urn@core3.amsl.com Delivered-To: urn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13D263A68ED for ; Wed, 28 Apr 2010 06:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sr3aQuc1mtOU for ; Wed, 28 Apr 2010 06:44:05 -0700 (PDT) Received: from mx1.renci.org (email.renci.org [152.54.4.63]) by core3.amsl.com (Postfix) with ESMTP id 77FB93A6AE5 for ; Wed, 28 Apr 2010 06:42:58 -0700 (PDT) Received: from wireless152023025161.med.unc.edu (wireless152023025161.med.unc.edu [152.23.25.161]) (authenticated bits=0) by mx1.renci.org (8.14.2/8.14.2) with ESMTP id o3SDgfPv018980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 28 Apr 2010 09:42:41 -0400 Message-ID: <4BD83B51.7010100@renci.org> Date: Wed, 28 Apr 2010 09:42:41 -0400 From: Xiaoshu Wang User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: urn@ietf.org References: <201004280802.KAA11778@TR-Sys.de> <4BD83069.6060407@gmx.de> In-Reply-To: <4BD83069.6060407@gmx.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-MS-Exchange-Organization-SCL: 0 X-Scanned-By: MIMEDefang 2.63 on 152.54.4.60 Subject: Re: [urn] fragment identifiers, Re: rfc2141bis [was: Re: A first cut at the Draft Charter ...] X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: xiao@renci.org List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 13:44:06 -0000 On 4/28/10 8:56 AM, Julian Reschke wrote: > On 28.04.2010 10:02, Alfred � wrote: > >> ... >> The primary questions are related to whether or not the general URN >> syntax should allow *new* or *revised* URN namespace definitions to >> explicitly admit and/or parts, and whether or >> not the few delimiter characters admitted in the revised URI syntax >> components but not in RFC 2141 should be allowed (without >> percent-encoding) in the URN syntax. >> > > ... > > URNs are URIs, right? According to RFC 3986, the fragment identifier is > entirely independent from the URI scheme: > > "The semantics of a fragment identifier are defined by the set of > representations that might result from a retrieval action on the primary > resource. The fragment's format and resolution is therefore dependent on > the media type [RFC2046] of a potentially retrieved representation, even > though such a retrieval is only performed if the URI is dereferenced. If > no such representation exists, then the semantics of the fragment are > considered unknown and are effectively unconstrained. Fragment > identifier semantics are independent of the URI scheme and thus cannot > be redefined by scheme specifications." -- > > > So the question here is: what's the purpose of a fragment identifier in > the absence of a representation? > The same question applies to a URN, with or without a fragment identifier. Let me rephrase your question as follows: "What is the purpose of a name in the absence of a representation?" A name does not necessarily refer to a representation. The retrieval of the representation of a thing referred to by a fragment identifier depends on the document type. It is no different from a URN that is absent of a fragment identifier. For example: both of the followings can be used as a name to refer an apple. (a) http://example.com/anApple (b) http://example.com/#anApple The difference is that, in case (b), the representation requires another retrieval mechanism other than HTTP. And this retrieval mechanism varies by MIME type. But that is the only difference. There isn't any inconsistencies between URI with or without fragment identifiers. Xiaoshu From moore@network-heretics.com Wed Apr 28 06:46:52 2010 Return-Path: X-Original-To: urn@core3.amsl.com Delivered-To: urn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 417CF3A6BDA for ; Wed, 28 Apr 2010 06:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.827 X-Spam-Level: X-Spam-Status: No, score=0.827 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, J_CHICKENPOX_38=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 NLiVpEysXR1O for ; Wed, 28 Apr 2010 06:46:51 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id EEF133A696F for ; Wed, 28 Apr 2010 06:46:05 -0700 (PDT) Received: from lust.indecency.org (174-151-122-31.pools.spcsdns.net [174.151.122.31]) by m1.imap-partners.net (MOS 4.1.8-GA) with ESMTP id BQY23126 (AUTH admin@network-heretics.com); Wed, 28 Apr 2010 06:45:46 -0700 X-Mirapoint-Received-SPF: 174.151.122.31 lust.indecency.org 5 none X-Mirapoint-Received-SPF: 174.151.122.31 lust.indecency.org 5 none X-Mirapoint-Received-SPF: 174.151.122.31 lust.indecency.org 5 none X-Mirapoint-Received-SPF: 174.151.122.31 lust.indecency.org 5 none Message-ID: <4BD83C09.10508@network-heretics.com> Date: Wed, 28 Apr 2010 09:45:45 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Julian Reschke References: <201004280802.KAA11778@TR-Sys.de> <4BD83069.6060407@gmx.de> <4BD836CF.1070402@network-heretics.com> <4BD839A3.4010404@gmx.de> In-Reply-To: <4BD839A3.4010404@gmx.de> Content-Type: multipart/alternative; boundary="------------050009020804050401030204" Cc: =?UTF-8?B?QWxmcmVkIO+/vQ==?= , urn@ietf.org Subject: Re: [urn] fragment identifiers, Re: rfc2141bis [was: Re: A first cut at the Draft Charter ...] X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 13:46:52 -0000 This is a multi-part message in MIME format. --------------050009020804050401030204 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 4/28/10 9:35 AM, Julian Reschke wrote: >> We could write a rule that says "don't use fragment ids with a URN >> unless those fragment ids are meaningful across all representations of >> the resources named by the URN." But I keep seeing examples that > > That would be almost the same rule as for any URL^HI. True. But we don't expect ordinary URIs to have persistent URI->resource bindings, which is the entire (original) reason for URNs. (Despite URNs being widely used today as unique names with no binding to any resource.) >> illustrate that people don't understand URNs or how they're to be used, >> even though the rules are quite simple. I suspect that adding more >> rules decreases the likelihood that people will use URNs correctly. >> >> But neither do I want to revise 3986 to say that fragment ids don't >> apply to URNs. That's a huge can of worms I'd prefer to leave closed. >> >> So maybe writing the rule is the best way. Though I have little >> confidence that it will be followed. > > What we need to do is to clarify that although fragment identifiers > aren't particularly useful unless you have representations, the URN > *syntax* - being compatible to RFC 3986 - allows them; and thus the > hash character needs to be percent-escaped in a URN. Certainly so if you want the hash character to be part of the base URN itself. I think it's also necessary to say something about the persistence (or lack thereof) of a URN#fragment -> resource fragment binding. Keith --------------050009020804050401030204 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 4/28/10 9:35 AM, Julian Reschke wrote:
We could write a rule that says "don't use fragment ids with a URN
unless those fragment ids are meaningful across all representations of
the resources named by the URN."  But I keep seeing examples that

That would be almost the same rule as for any URL^HI.
True.  But we don't expect ordinary URIs to have persistent URI->resource bindings, which is the entire (original) reason for URNs. 
(Despite URNs being widely used today as unique names with no binding to any resource.)
illustrate that people don't understand URNs or how they're to be used,
even though the rules are quite simple.   I suspect that adding more
rules decreases the likelihood that people will use URNs correctly.

But neither do I want to revise 3986 to say that fragment ids don't
apply to URNs.  That's a huge can of worms I'd prefer to leave closed.

So maybe writing the rule is the best way.   Though I have little
confidence that it will be followed.

What we need to do is to clarify that although fragment identifiers aren't particularly useful unless you have representations, the URN *syntax* - being compatible to RFC 3986 - allows them; and thus the hash character needs to be percent-escaped in a URN.
Certainly so if you want the hash character to be part of the base URN itself.

I think it's also necessary to say something about the persistence (or lack thereof) of a URN#fragment -> resource fragment binding.

Keith

 --------------050009020804050401030204-- From moore@network-heretics.com Wed Apr 28 07:00:48 2010 Return-Path: X-Original-To: urn@core3.amsl.com Delivered-To: urn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3DDD3A69CF for ; Wed, 28 Apr 2010 07:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.652 X-Spam-Level: X-Spam-Status: No, score=0.652 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_38=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 UJXPktd77ewm for ; Wed, 28 Apr 2010 07:00:47 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 0D65C3A6951 for ; Wed, 28 Apr 2010 07:00:47 -0700 (PDT) Received: from lust.indecency.org (174-151-122-31.pools.spcsdns.net [174.151.122.31]) by m1.imap-partners.net (MOS 4.1.8-GA) with ESMTP id BQY26552 (AUTH admin@network-heretics.com); Wed, 28 Apr 2010 07:00:30 -0700 X-Mirapoint-Received-SPF: 174.151.122.31 lust.indecency.org 5 none X-Mirapoint-Received-SPF: 174.151.122.31 lust.indecency.org 5 none X-Mirapoint-Received-SPF: 174.151.122.31 lust.indecency.org 5 none Message-ID: <4BD83F7D.1050100@network-heretics.com> Date: Wed, 28 Apr 2010 10:00:29 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: xiao@renci.org References: <201004280802.KAA11778@TR-Sys.de> <4BD83069.6060407@gmx.de> <4BD83B51.7010100@renci.org> In-Reply-To: <4BD83B51.7010100@renci.org> Content-Type: multipart/alternative; boundary="------------000102040409030400080404" Cc: urn@ietf.org Subject: Re: [urn] fragment identifiers, Re: rfc2141bis [was: Re: A first cut at the Draft Charter ...] X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 14:00:48 -0000 This is a multi-part message in MIME format. --------------000102040409030400080404 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 4/28/10 9:42 AM, Xiaoshu Wang wrote: >> So the question here is: what's the purpose of a fragment identifier in >> the absence of a representation? > The same question applies to a URN, with or without a fragment > identifier. Let me rephrase your question as follows: > > "What is the purpose of a name in the absence of a representation?" > > A name does not necessarily refer to a representation. The retrieval > of the representation of a thing referred to by a fragment identifier > depends on the document type. More precisely, it depends on the representation. Different representations of a resource can have the same document type (content-type) and still not use fragment identifiers in the same way. Consider the problem of translating a document from one language to another. The original document contains named fragments of text which (due to differences in the way things are expressed in the different languages) do not cleanly map from the original document to the translation. In general there are just too many barriers to expecting, as a matter of web architecture, that fragment identifiers mean the same thing across different representations of a resource. Basically, this was not a well thought out aspect of the design of the web. Content-negotiation was not anticipated. While it makes sense for HTML to have the ability to name subsections of a document, fragment identifiers in URIs were never designed to be stable across different representations of a resource. Even in those cases where URL#fragment is useful, there's no assurance that, given a URN that is associated with the same resource as that URL, URN#fragment is similarly useful. > It is no different from a URN that is absent of a fragment identifier. > > For example: both of the followings can be used as a name to refer an > apple. > > (a) http://example.com/anApple > (b) http://example.com/#anApple > > The difference is that, in case (b), the representation requires > another retrieval mechanism other than HTTP. And this retrieval > mechanism varies by MIME type. But that is the only difference. There > isn't any inconsistencies between URI with or without fragment > identifiers. Uh, no. It makes no sense to have different syntaxes for a URI in different contexts. The # character (if it appears in a URI) MUST always separate a base URI from a fragment identifier, and for any URI which is bound to a resource, the way the base URI vs. fragment identifier are parsed MUST be independent of the access mechanism. Keith --------------000102040409030400080404 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 4/28/10 9:42 AM, Xiaoshu Wang wrote:
So the question here is: what's the purpose of a fragment identifier in
the absence of a representation?
The same question applies to a URN, with or without a fragment identifier. Let me rephrase your question as follows:

"What is the purpose of a name in the absence of a representation?"

A name does not necessarily refer to a representation. The retrieval of the representation of a thing referred to by a fragment identifier depends on the document type.
More precisely, it depends on the representation.  Different representations of a resource can have the same document type (content-type) and still not use fragment identifiers in the same way. 

Consider the problem of translating a document from one language to another.  The original document contains named fragments of text which (due to differences in the way things are expressed in the different languages) do not cleanly map from the original document to the translation.   In general there are just too many barriers to expecting, as a matter of web architecture, that fragment identifiers mean the same thing across different representations of a resource.

Basically, this was not a well thought out aspect of the design of the web.   Content-negotiation was not anticipated.    While it makes sense for HTML to have the ability to name subsections of a document, fragment identifiers in URIs were never designed to be stable across different representations of a resource.  

Even in those cases where URL#fragment is useful, there's no assurance that, given a URN that is associated with the same resource as that URL, URN#fragment is similarly useful.
It is no different from a URN that is absent of a fragment identifier.

For example: both of the followings can be used as a name to refer an apple.

(a) http://example.com/anApple
(b) http://example.com/#anApple

The difference is that, in case (b), the representation requires another retrieval mechanism other than HTTP. And this retrieval mechanism varies by MIME type. But that is the only difference. There isn't any inconsistencies between URI with or without fragment identifiers.
Uh, no.  It makes no sense to have different syntaxes for a URI in different contexts.   The # character (if it appears in a URI) MUST always separate a base URI from a fragment identifier, and for any URI which is bound to a resource, the way the base URI vs. fragment identifier are parsed MUST be independent of the access mechanism.

Keith

--------------000102040409030400080404-- From xiao@renci.org Wed Apr 28 07:27:42 2010 Return-Path: X-Original-To: urn@core3.amsl.com Delivered-To: urn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 101B63A6951 for ; Wed, 28 Apr 2010 07:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_38=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 vRqBYZFZMqyf for ; Wed, 28 Apr 2010 07:27:40 -0700 (PDT) Received: from mx1.renci.org (email.renci.org [152.54.4.63]) by core3.amsl.com (Postfix) with ESMTP id AC5AE3A68FA for ; Wed, 28 Apr 2010 07:27:39 -0700 (PDT) Received: from wireless152023025161.med.unc.edu (wireless152023025161.med.unc.edu [152.23.25.161]) (authenticated bits=0) by mx1.renci.org (8.14.2/8.14.2) with ESMTP id o3SERP5f025397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Apr 2010 10:27:26 -0400 Message-ID: <4BD845CD.4060100@renci.org> Date: Wed, 28 Apr 2010 10:27:25 -0400 From: Xiaoshu Wang User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Keith Moore References: <201004280802.KAA11778@TR-Sys.de> <4BD83069.6060407@gmx.de> <4BD83B51.7010100@renci.org> <4BD83F7D.1050100@network-heretics.com> In-Reply-To: <4BD83F7D.1050100@network-heretics.com> Content-Type: multipart/alternative; boundary="------------060901040809060504080106" X-MS-Exchange-Organization-SCL: 0 X-Scanned-By: MIMEDefang 2.63 on 152.54.4.60 Cc: "urn@ietf.org" Subject: Re: [urn] fragment identifiers, Re: rfc2141bis [was: Re: A first cut at the Draft Charter ...] X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: xiao@renci.org List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 14:27:42 -0000 This is a multi-part message in MIME format. --------------060901040809060504080106 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 4/28/10 10:00 AM, Keith Moore wrote: > On 4/28/10 9:42 AM, Xiaoshu Wang wrote: >>> So the question here is: what's the purpose of a fragment identifier in >>> the absence of a representation? >> The same question applies to a URN, with or without a fragment >> identifier. Let me rephrase your question as follows: >> >> "What is the purpose of a name in the absence of a representation?" >> >> A name does not necessarily refer to a representation. The retrieval >> of the representation of a thing referred to by a fragment identifier >> depends on the document type. > More precisely, it depends on the representation. Different > representations of a resource can have the same document type > (content-type) and still not use fragment identifiers in the same way. > > Consider the problem of translating a document from one language to > another. The original document contains named fragments of text which > (due to differences in the way things are expressed in the different > languages) do not cleanly map from the original document to the > translation. In general there are just too many barriers to > expecting, as a matter of web architecture, that fragment identifiers > mean the same thing across different representations of a resource. Right. But we can describe an apple in different languages. But the apple is the apple. The URI does not refer to the representation. Of course, it can made it be. But if so, it requires to be explicitly specified. > Basically, this was not a well thought out aspect of the design of the > web. Content-negotiation was not anticipated. While it makes > sense for HTML to have the ability to name subsections of a document, > fragment identifiers in URIs were never designed to be stable across > different representations of a resource. If the following three URIs are used to refer to the same thing, say, an apple (a) http://a.com/anApple (say only return an HTML representation) (b) http://b.com/anApple (say only return a JPEG representation) (c) http://c.com/#anApple (return both an HTML and JPEG representation via content negotiation) (c1) the HTML representation of "http://c.com/#anApple" (c2) the JPEG representation of "http://c.com/#anApple" Is there any difference that if (a) and (b) are inconsistent vs. the case that (c1) and (c2) are inconsistent? > Even in those cases where URL#fragment is useful, there's no assurance > that, given a URN that is associated with the same resource as that > URL, URN#fragment is similarly useful. My point is that it doesn't matter if there is a fragment identifier or not. A URI is a URI. The path to its representation may differ; but it doesn't matter what a URI is used to refer to something. >> It is no different from a URN that is absent of a fragment identifier. >> >> For example: both of the followings can be used as a name to refer an >> apple. >> >> (a) http://example.com/anApple >> (b) http://example.com/#anApple >> >> The difference is that, in case (b), the representation requires >> another retrieval mechanism other than HTTP. And this retrieval >> mechanism varies by MIME type. But that is the only difference. There >> isn't any inconsistencies between URI with or without fragment >> identifiers. > Uh, no. It makes no sense to have different syntaxes for a URI in > different contexts. The # character (if it appears in a URI) MUST > always separate a base URI from a fragment identifier, and for any URI > which is bound to a resource, the way the base URI vs. fragment > identifier are parsed MUST be independent of the access mechanism. I didn't mean to have different syntax in different context. I am trying to illustrate that whether a URI has a fragment identifier or not is irrelevant to the issue of naming. We have to understand that what a URI references is not the same as what is de-referenced from the URI. The de-reference process of a URI with a fragment identifier is a bit different from those that are not. But it has nothing to do with what the URI references. Xiaoshu --------------060901040809060504080106 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 4/28/10 10:00 AM, Keith Moore wrote:
On 4/28/10 9:42 AM, Xiaoshu Wang wrote:
So the question here is: what's the purpose of a fragment identifier in
the absence of a representation?
The same question applies to a URN, with or without a fragment identifier. Let me rephrase your question as follows:

"What is the purpose of a name in the absence of a representation?"

A name does not necessarily refer to a representation. The retrieval of the representation of a thing referred to by a fragment identifier depends on the document type.
More precisely, it depends on the representation.  Different representations of a resource can have the same document type (content-type) and still not use fragment identifiers in the same way. 

Consider the problem of translating a document from one language to another.  The original document contains named fragments of text which (due to differences in the way things are expressed in the different languages) do not cleanly map from the original document to the translation.   In general there are just too many barriers to expecting, as a matter of web architecture, that fragment identifiers mean the same thing across different representations of a resource.
Right. But we can describe an apple in different languages. But the apple is the apple. The URI does not refer to the representation. Of course, it can made it be. But if so, it requires to be explicitly specified.
Basically, this was not a well thought out aspect of the design of the web.   Content-negotiation was not anticipated.    While it makes sense for HTML to have the ability to name subsections of a document, fragment identifiers in URIs were never designed to be stable across different representations of a resource. 
If the following three URIs are used to refer to the same thing, say, an apple

(a) http://a.com/anApple (say only return an HTML representation)
(b) http://b.com/anApple (say only return a JPEG representation)
(c) http://c.com/#anApple (return both an HTML and JPEG representation via content negotiation)
    (c1) the HTML representation of "http://c.com/#anApple"
    (c2) the JPEG representation of "http://c.com/#anApple"

Is there any difference that if (a) and (b) are inconsistent vs. the case that (c1) and (c2) are inconsistent?
Even in those cases where URL#fragment is useful, there's no assurance that, given a URN that is associated with the same resource as that URL, URN#fragment is similarly useful.
My point is that it doesn't matter if there is a fragment identifier or not. A URI is a URI. The path to its representation may differ; but it doesn't matter what a URI is used to refer to something.

It is no different from a URN that is absent of a fragment identifier.

For example: both of the followings can be used as a name to refer an apple.

(a) http://example.com/anApple
(b) http://example.com/#anApple

The difference is that, in case (b), the representation requires another retrieval mechanism other than HTTP. And this retrieval mechanism varies by MIME type. But that is the only difference. There isn't any inconsistencies between URI with or without fragment identifiers.
Uh, no.  It makes no sense to have different syntaxes for a URI in different contexts.   The # character (if it appears in a URI) MUST always separate a base URI from a fragment identifier, and for any URI which is bound to a resource, the way the base URI vs. fragment identifier are parsed MUST be independent of the access mechanism.
I didn't mean to have different syntax in different context. I am trying to illustrate that whether a URI has a fragment identifier or not is irrelevant to the issue of naming. We have to understand that what a URI references is not the same as what is de-referenced from the URI. The de-reference process of a URI with a fragment identifier is a bit different from those that are not. But it has nothing to do with what the URI references.

Xiaoshu

--------------060901040809060504080106-- From moore@network-heretics.com Wed Apr 28 07:35:40 2010 Return-Path: X-Original-To: urn@core3.amsl.com Delivered-To: urn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A12823A6B81 for ; Wed, 28 Apr 2010 07:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.339 X-Spam-Level: X-Spam-Status: No, score=0.339 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_50=0.001, 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 I9VG5Zf4L1Jm for ; Wed, 28 Apr 2010 07:35:39 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 481063A6AE9 for ; Wed, 28 Apr 2010 07:35:39 -0700 (PDT) Received: from lust.indecency.org (174-151-122-31.pools.spcsdns.net [174.151.122.31]) by m1.imap-partners.net (MOS 4.1.8-GA) with ESMTP id BQY34181 (AUTH admin@network-heretics.com); Wed, 28 Apr 2010 07:35:15 -0700 X-Mirapoint-Received-SPF: 174.151.122.31 lust.indecency.org 5 none X-Mirapoint-Received-SPF: 174.151.122.31 lust.indecency.org 5 none X-Mirapoint-Received-SPF: 174.151.122.31 lust.indecency.org 5 none Message-ID: <4BD847A2.8090204@network-heretics.com> Date: Wed, 28 Apr 2010 10:35:14 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: xiao@renci.org References: <201004280802.KAA11778@TR-Sys.de> <4BD83069.6060407@gmx.de> <4BD83B51.7010100@renci.org> <4BD83F7D.1050100@network-heretics.com> <4BD845CD.4060100@renci.org> In-Reply-To: <4BD845CD.4060100@renci.org> Content-Type: multipart/alternative; boundary="------------080901020802060108020707" Cc: "urn@ietf.org" Subject: Re: [urn] fragment identifiers, Re: rfc2141bis [was: Re: A first cut at the Draft Charter ...] X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 14:35:40 -0000 This is a multi-part message in MIME format. --------------080901020802060108020707 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 4/28/10 10:27 AM, Xiaoshu Wang wrote: > We have to understand that what a URI references is not the same as > what is de-referenced from the URI. Well, IMO, that makes very little sense. I realize that there's a growing tendency to use URIs as pure names, or as names that don't refer specifically to a network-accessible resource - and then to say that if de-referencing the URI over the network happens to return a resource, that it's not the same thing as what is named by the URI. But neither URIs nor the other mechanisms associated with the web were designed to work this way. Trying to re-justify all of the existing notations, protocols, and other infrastructure in terms of some more abstract (and revisionist) idea of what URIs are, is silly, and has no place in an organization that purports to do engineering. Keith --------------080901020802060108020707 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 4/28/10 10:27 AM, Xiaoshu Wang wrote:
We have to understand that what a URI references is not the same as what is de-referenced from the URI.
Well, IMO, that makes very little sense.  I realize that there's a growing tendency to use URIs as pure names, or as names that don't refer specifically to a network-accessible resource - and then to say that if de-referencing the URI over the network happens to return a resource, that it's not the same thing as what is named by the URI.  But neither URIs nor the other mechanisms associated with the web were designed to work this way.  Trying to re-justify all of the existing notations, protocols, and other infrastructure in terms of some more abstract (and revisionist) idea of what URIs are, is silly, and has no place in an organization that purports to do engineering.

Keith

--------------080901020802060108020707-- From xiao@renci.org Wed Apr 28 07:45:41 2010 Return-Path: X-Original-To: urn@core3.amsl.com Delivered-To: urn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD6533A6A66 for ; Wed, 28 Apr 2010 07:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.219 X-Spam-Level: X-Spam-Status: No, score=-0.219 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_20=-0.74, 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 LOHWSdGqdDM9 for ; Wed, 28 Apr 2010 07:45:41 -0700 (PDT) Received: from mx1.renci.org (email.renci.org [152.54.4.63]) by core3.amsl.com (Postfix) with ESMTP id B6EDB3A6C2C for ; Wed, 28 Apr 2010 07:43:03 -0700 (PDT) Received: from wireless152023025161.med.unc.edu (wireless152023025161.med.unc.edu [152.23.25.161]) (authenticated bits=0) by mx1.renci.org (8.14.2/8.14.2) with ESMTP id o3SEgouc027413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Apr 2010 10:42:50 -0400 Message-ID: <4BD84969.9000109@renci.org> Date: Wed, 28 Apr 2010 10:42:49 -0400 From: Xiaoshu Wang User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Keith Moore References: <201004280802.KAA11778@TR-Sys.de> <4BD83069.6060407@gmx.de> <4BD83B51.7010100@renci.org> <4BD83F7D.1050100@network-heretics.com> <4BD845CD.4060100@renci.org> <4BD847A2.8090204@network-heretics.com> In-Reply-To: <4BD847A2.8090204@network-heretics.com> Content-Type: multipart/alternative; boundary="------------090103090106090502090501" X-MS-Exchange-Organization-SCL: 0 X-Scanned-By: MIMEDefang 2.63 on 152.54.4.60 Cc: "urn@ietf.org" Subject: Re: [urn] fragment identifiers, Re: rfc2141bis [was: Re: A first cut at the Draft Charter ...] X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: xiao@renci.org List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 14:45:41 -0000 This is a multi-part message in MIME format. --------------090103090106090502090501 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 4/28/10 10:35 AM, Keith Moore wrote: > On 4/28/10 10:27 AM, Xiaoshu Wang wrote: >> We have to understand that what a URI references is not the same as >> what is de-referenced from the URI. > Well, IMO, that makes very little sense. I realize that there's a > growing tendency to use URIs as pure names, or as names that don't > refer specifically to a network-accessible resource - and then to say > that if de-referencing the URI over the network happens to return a > resource, that it's not the same thing as what is named by the URI. > But neither URIs nor the other mechanisms associated with the web were > designed to work this way. Trying to re-justify all of the existing > notations, protocols, and other infrastructure in terms of some more > abstract (and revisionist) idea of what URIs are, is silly, and has no > place in an organization that purports to do engineering. Well, I disagree. But what is the purpose of this URN mailing list? I am not sure what you mean by "use URIs as pure names, ...". Can you define: -- What is "a pure name"? -- What is a network-accessible resource? Is knowledge engineering what all of us ultimately want to do? If not, what is it? And if so, I guess that we cannot avoid these hard questions. Xiaoshu --------------090103090106090502090501 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 4/28/10 10:35 AM, Keith Moore wrote:
On 4/28/10 10:27 AM, Xiaoshu Wang wrote:
We have to understand that what a URI references is not the same as what is de-referenced from the URI.
Well, IMO, that makes very little sense.  I realize that there's a growing tendency to use URIs as pure names, or as names that don't refer specifically to a network-accessible resource - and then to say that if de-referencing the URI over the network happens to return a resource, that it's not the same thing as what is named by the URI.  But neither URIs nor the other mechanisms associated with the web were designed to work this way.  Trying to re-justify all of the existing notations, protocols, and other infrastructure in terms of some more abstract (and revisionist) idea of what URIs are, is silly, and has no place in an organization that purports to do engineering.
Well, I disagree. But what is the purpose of this URN mailing list? I am not sure what you mean by "use URIs as pure names, ...". Can you define:

-- What is "a pure name"?
-- What is a network-accessible resource?

Is knowledge engineering what all of us ultimately want to do? If not, what is it? And if so, I guess that we cannot avoid these hard questions.

Xiaoshu
--------------090103090106090502090501-- From julian.reschke@gmx.de Wed Apr 28 07:57:35 2010 Return-Path: X-Original-To: urn@core3.amsl.com Delivered-To: urn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD27B3A6C2C for ; Wed, 28 Apr 2010 07:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.114 X-Spam-Level: X-Spam-Status: No, score=-3.114 tagged_above=-999 required=5 tests=[AWL=-3.115, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8zBLadP2Hq3 for ; Wed, 28 Apr 2010 07:57:34 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 5632D3A6C05 for ; Wed, 28 Apr 2010 07:54:10 -0700 (PDT) Received: (qmail invoked by alias); 28 Apr 2010 14:53:56 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.116]) [217.91.35.233] by mail.gmx.net (mp059) with SMTP; 28 Apr 2010 16:53:56 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+4VJ8Vs9a4PAv/WlLKkwND+poZqwd9HX5SLGMi3P NPheMQUiN3KyZl Message-ID: <4BD84BFD.20608@gmx.de> Date: Wed, 28 Apr 2010 16:53:49 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Keith Moore References: <201004280802.KAA11778@TR-Sys.de> <4BD83069.6060407@gmx.de> <4BD83B51.7010100@renci.org> <4BD83F7D.1050100@network-heretics.com> <4BD845CD.4060100@renci.org> <4BD847A2.8090204@network-heretics.com> In-Reply-To: <4BD847A2.8090204@network-heretics.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57999999999999996 Cc: "urn@ietf.org" Subject: Re: [urn] fragment identifiers, Re: rfc2141bis [was: Re: A first cut at the Draft Charter ...] X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 14:57:35 -0000 Keith, On 28.04.2010 16:35, Keith Moore wrote: > On 4/28/10 10:27 AM, Xiaoshu Wang wrote: >> We have to understand that what a URI references is not the same as >> what is de-referenced from the URI. > Well, IMO, that makes very little sense. I realize that there's a > growing tendency to use URIs as pure names, or as names that don't refer > specifically to a network-accessible resource - and then to say that if > de-referencing the URI over the network happens to return a resource, > that it's not the same thing as what is named by the URI. But neither What's returned isn't the resource, but a representation of the resource. > URIs nor the other mechanisms associated with the web were designed to > work this way. Trying to re-justify all of the existing notations, > protocols, and other infrastructure in terms of some more abstract (and > revisionist) idea of what URIs are, is silly, and has no place in an > organization that purports to do engineering. could you clarify whether you want to challenge this part of RFC 3986? "When URIs are used within information retrieval systems to identify sources of information, the most common form of URI dereference is "retrieval": making use of a URI in order to retrieve a representation of its associated resource. A "representation" is a sequence of octets, along with representation metadata describing those octets, that constitutes a record of the state of the resource at the time when the representation is generated. Retrieval is achieved by a process that might include using the URI as a cache key to check for a locally cached representation, resolution of the URI to determine an appropriate access mechanism (if any), and dereference of the URI for the sake of applying a retrieval operation. Depending on the protocols used to perform the retrieval, additional information might be supplied about the resource (resource metadata) and its relation to other resources." -- ? Best regards, Julian From moore@network-heretics.com Wed Apr 28 09:25:09 2010 Return-Path: X-Original-To: urn@core3.amsl.com Delivered-To: urn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 095883A6A36 for ; Wed, 28 Apr 2010 09:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.272 X-Spam-Level: X-Spam-Status: No, score=0.272 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_50=0.001, 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 suebXVIcoJh6 for ; Wed, 28 Apr 2010 09:25:06 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 459C23A6809 for ; Wed, 28 Apr 2010 09:25:04 -0700 (PDT) Received: from lust.indecency.org (174-151-122-31.pools.spcsdns.net [174.151.122.31]) by m1.imap-partners.net (MOS 4.1.8-GA) with ESMTP id BQY59598 (AUTH admin@network-heretics.com); Wed, 28 Apr 2010 09:24:40 -0700 X-Mirapoint-Received-SPF: 174.151.122.31 lust.indecency.org 5 none X-Mirapoint-Received-SPF: 174.151.122.31 lust.indecency.org 5 none X-Mirapoint-Received-SPF: 174.151.122.31 lust.indecency.org 5 none Message-ID: <4BD86147.3030401@network-heretics.com> Date: Wed, 28 Apr 2010 12:24:39 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: xiao@renci.org References: <201004280802.KAA11778@TR-Sys.de> <4BD83069.6060407@gmx.de> <4BD83B51.7010100@renci.org> <4BD83F7D.1050100@network-heretics.com> <4BD845CD.4060100@renci.org> <4BD847A2.8090204@network-heretics.com> <4BD84969.9000109@renci.org> In-Reply-To: <4BD84969.9000109@renci.org> Content-Type: multipart/alternative; boundary="------------010306070703000103050108" Cc: "urn@ietf.org" Subject: Re: [urn] fragment identifiers, Re: rfc2141bis [was: Re: A first cut at the Draft Charter ...] X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 16:25:09 -0000 This is a multi-part message in MIME format. --------------010306070703000103050108 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 4/28/10 10:42 AM, Xiaoshu Wang wrote: > On 4/28/10 10:35 AM, Keith Moore wrote: >> On 4/28/10 10:27 AM, Xiaoshu Wang wrote: >>> We have to understand that what a URI references is not the same as >>> what is de-referenced from the URI. >> Well, IMO, that makes very little sense. I realize that there's a >> growing tendency to use URIs as pure names, or as names that don't >> refer specifically to a network-accessible resource - and then to say >> that if de-referencing the URI over the network happens to return a >> resource, that it's not the same thing as what is named by the URI. >> But neither URIs nor the other mechanisms associated with the web >> were designed to work this way. Trying to re-justify all of the >> existing notations, protocols, and other infrastructure in terms of >> some more abstract (and revisionist) idea of what URIs are, is silly, >> and has no place in an organization that purports to do engineering. > Well, I disagree. But what is the purpose of this URN mailing list? I > am not sure what you mean by "use URIs as pure names, ...". Can you > define: > > -- What is "a pure name"? This is a term we were using many years ago in the original URN discussions. I never saw a formal definition of the term. My best attempt to define a pure name would be a name that isn't bound to anything that exists in concrete or tangible form. If it's bound to anything, it's an abstract concept. It's meaningless to speak of de-referencing or accessing the resource associated with a pure name. > -- What is a network-accessible resource? It's a resource that can be accessed using the network. If the resource named by http://foo.com/bar.doc is a Microsoft Word document, and you can download that resource from the indicated web site, it's a network-accessible resource. (Often the resource and the representation really are the same thing.) > Is knowledge engineering what all of us ultimately want to do? If not, > what is it? And if so, I guess that we cannot avoid these hard questions. I can't answer that question for others. But I can confidently say that trying to take an extremely widely deployed architecture and infrastructure, and trying to redefine its behavior in a way that conflicts with its design and widespread use, is unlikely to be successful. Ultimately our job here is to write specifications that will be used to implement code that works consistently between implementations and across the entire Internet. We can't do that if what we specify conflicts with widespread existing practice. And when we talk about using well-established protocols like http URIs or even URNs in an abstract fashion that doesn't consider the huge body of existing practice, it's hard to imagine that anything useful will come of it. Keith --------------010306070703000103050108 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 4/28/10 10:42 AM, Xiaoshu Wang wrote:
On 4/28/10 10:35 AM, Keith Moore wrote:
On 4/28/10 10:27 AM, Xiaoshu Wang wrote:
We have to understand that what a URI references is not the same as what is de-referenced from the URI.
Well, IMO, that makes very little sense.  I realize that there's a growing tendency to use URIs as pure names, or as names that don't refer specifically to a network-accessible resource - and then to say that if de-referencing the URI over the network happens to return a resource, that it's not the same thing as what is named by the URI.  But neither URIs nor the other mechanisms associated with the web were designed to work this way.  Trying to re-justify all of the existing notations, protocols, and other infrastructure in terms of some more abstract (and revisionist) idea of what URIs are, is silly, and has no place in an organization that purports to do engineering.
Well, I disagree. But what is the purpose of this URN mailing list? I am not sure what you mean by "use URIs as pure names, ...". Can you define:

-- What is "a pure name"?
This is a term we were using many years ago in the original URN discussions.   I never saw a formal definition of the term.  My best attempt to define a pure name would be a name that isn't bound to anything that exists in concrete or tangible form.  If it's bound to anything, it's an abstract concept.   It's meaningless to speak of de-referencing or accessing the resource associated with a pure name.
-- What is a network-accessible resource?
It's a resource that can be accessed using the network.  If the resource named by http://foo.com/bar.doc is a Microsoft Word document, and you can download that resource from the indicated web site, it's a network-accessible resource.  (Often the resource and the representation really are the same thing.)
Is knowledge engineering what all of us ultimately want to do? If not, what is it? And if so, I guess that we cannot avoid these hard questions.
I can't answer that question for others.  But I can confidently say that trying to take an extremely widely deployed architecture and infrastructure, and trying to redefine its behavior in a way that conflicts with its design and widespread use, is unlikely to be successful.   Ultimately our job here is to write specifications that will be used to implement code that works consistently between implementations and across the entire Internet.  We can't do that if what we specify conflicts with widespread existing practice.  And when we talk about using well-established protocols like http URIs or even URNs in an abstract fashion that doesn't consider the huge body of existing practice, it's hard to imagine that anything useful will come of it.

Keith

--------------010306070703000103050108-- From xiao@renci.org Wed Apr 28 09:35:40 2010 Return-Path: X-Original-To: urn@core3.amsl.com Delivered-To: urn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 538153A69DF for ; Wed, 28 Apr 2010 09:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.022 X-Spam-Level: X-Spam-Status: No, score=-0.022 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_50=0.001, 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 CzY4y5uhPf9V for ; Wed, 28 Apr 2010 09:35:38 -0700 (PDT) Received: from mx1.renci.org (email.renci.org [152.54.4.63]) by core3.amsl.com (Postfix) with ESMTP id 8A4383A685D for ; Wed, 28 Apr 2010 09:35:38 -0700 (PDT) Received: from wireless152023025161.med.unc.edu (wireless152023025161.med.unc.edu [152.23.25.161]) (authenticated bits=0) by mx1.renci.org (8.14.2/8.14.2) with ESMTP id o3SGZOTi009046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Apr 2010 12:35:24 -0400 Message-ID: <4BD863CA.3050004@renci.org> Date: Wed, 28 Apr 2010 12:35:22 -0400 From: Xiaoshu Wang User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Keith Moore References: <201004280802.KAA11778@TR-Sys.de> <4BD83069.6060407@gmx.de> <4BD83B51.7010100@renci.org> <4BD83F7D.1050100@network-heretics.com> <4BD845CD.4060100@renci.org> <4BD847A2.8090204@network-heretics.com> <4BD84969.9000109@renci.org> <4BD86147.3030401@network-heretics.com> In-Reply-To: <4BD86147.3030401@network-heretics.com> Content-Type: multipart/alternative; boundary="------------070607050201020101060608" X-MS-Exchange-Organization-SCL: 0 X-Scanned-By: MIMEDefang 2.63 on 152.54.4.60 Cc: "urn@ietf.org" Subject: Re: [urn] fragment identifiers, Re: rfc2141bis [was: Re: A first cut at the Draft Charter ...] X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: xiao@renci.org List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 16:35:40 -0000 This is a multi-part message in MIME format. --------------070607050201020101060608 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 4/28/10 12:24 PM, Keith Moore wrote: > On 4/28/10 10:42 AM, Xiaoshu Wang wrote: >> On 4/28/10 10:35 AM, Keith Moore wrote: >>> On 4/28/10 10:27 AM, Xiaoshu Wang wrote: >>>> We have to understand that what a URI references is not the same as >>>> what is de-referenced from the URI. >>> Well, IMO, that makes very little sense. I realize that there's a >>> growing tendency to use URIs as pure names, or as names that don't >>> refer specifically to a network-accessible resource - and then to >>> say that if de-referencing the URI over the network happens to >>> return a resource, that it's not the same thing as what is named by >>> the URI. But neither URIs nor the other mechanisms associated with >>> the web were designed to work this way. Trying to re-justify all of >>> the existing notations, protocols, and other infrastructure in terms >>> of some more abstract (and revisionist) idea of what URIs are, is >>> silly, and has no place in an organization that purports to do >>> engineering. >> Well, I disagree. But what is the purpose of this URN mailing list? I >> am not sure what you mean by "use URIs as pure names, ...". Can you >> define: >> >> -- What is "a pure name"? > This is a term we were using many years ago in the original URN > discussions. I never saw a formal definition of the term. My best > attempt to define a pure name would be a name that isn't bound to > anything that exists in concrete or tangible form. If it's bound to > anything, it's an abstract concept. It's meaningless to speak of > de-referencing or accessing the resource associated with a pure name. If a name is bound to nothing. It is useless. Any name is bound with a *transportation* protocol. The names that we use in natural language is bound to our cognitive system. A pure name, in the sense that is not bound with any retrieval protocol, doesn't exist. >> -- What is a network-accessible resource? > It's a resource that can be accessed using the network. If the > resource named by http://foo.com/bar.doc is a Microsoft Word document, > and you can download that resource from the indicated web site, it's a > network-accessible resource. (Often the resource and the > representation really are the same thing.) "http://foo.com/bar.doc" can be potentially bound with an HTML representation. What is this network-accessible resource? I can use "http://example.com/earth" to name the Earth. Is the earth network-accessible resource? >> Is knowledge engineering what all of us ultimately want to do? If >> not, what is it? And if so, I guess that we cannot avoid these hard >> questions. > I can't answer that question for others. But I can confidently say > that trying to take an extremely widely deployed architecture and > infrastructure, and trying to redefine its behavior in a way that > conflicts with its design and widespread use, is unlikely to be > successful. Who said there is a conflict? Isn't what I am trying to say is that: there is an ontological ground that there is not a conflict. But once you insist that reference and dereference are symmetric relation, it is this thesis that is heading to trouble. > Ultimately our job here is to write specifications that will be used > to implement code that works consistently between implementations and > across the entire Internet. We can't do that if what we specify > conflicts with widespread existing practice. Right. But who is doing that? > And when we talk about using well-established protocols like http URIs > or even URNs in an abstract fashion that doesn't consider the huge > body of existing practice, it's hard to imagine that anything useful > will come of it. You bring another ambiguous concept -- "abstraction" -- into discussion. Again, it will be your burden of proof to clarify the distinction. Xiaoshu --------------070607050201020101060608 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 4/28/10 12:24 PM, Keith Moore wrote:
On 4/28/10 10:42 AM, Xiaoshu Wang wrote:
On 4/28/10 10:35 AM, Keith Moore wrote:
On 4/28/10 10:27 AM, Xiaoshu Wang wrote:
We have to understand that what a URI references is not the same as what is de-referenced from the URI.
Well, IMO, that makes very little sense.  I realize that there's a growing tendency to use URIs as pure names, or as names that don't refer specifically to a network-accessible resource - and then to say that if de-referencing the URI over the network happens to return a resource, that it's not the same thing as what is named by the URI.  But neither URIs nor the other mechanisms associated with the web were designed to work this way.  Trying to re-justify all of the existing notations, protocols, and other infrastructure in terms of some more abstract (and revisionist) idea of what URIs are, is silly, and has no place in an organization that purports to do engineering.
Well, I disagree. But what is the purpose of this URN mailing list? I am not sure what you mean by "use URIs as pure names, ...". Can you define:

-- What is "a pure name"?
This is a term we were using many years ago in the original URN discussions.   I never saw a formal definition of the term.  My best attempt to define a pure name would be a name that isn't bound to anything that exists in concrete or tangible form.  If it's bound to anything, it's an abstract concept.   It's meaningless to speak of de-referencing or accessing the resource associated with a pure name.
If a name is bound to nothing. It is useless. Any name is bound with a *transportation* protocol. The names that we use in natural language is bound to our cognitive system. A pure name, in the sense that is not bound with any retrieval protocol, doesn't exist.
-- What is a network-accessible resource?
It's a resource that can be accessed using the network.  If the resource named by http://foo.com/bar.doc is a Microsoft Word document, and you can download that resource from the indicated web site, it's a network-accessible resource.  (Often the resource and the representation really are the same thing.)
"http://foo.com/bar.doc" can be potentially bound with an HTML representation. What is this network-accessible resource? I can use "http://example.com/earth" to name the Earth. Is the earth network-accessible resource?
Is knowledge engineering what all of us ultimately want to do? If not, what is it? And if so, I guess that we cannot avoid these hard questions.
I can't answer that question for others.  But I can confidently say that trying to take an extremely widely deployed architecture and infrastructure, and trying to redefine its behavior in a way that conflicts with its design and widespread use, is unlikely to be successful.  
Who said there is a conflict? Isn't what I am trying to say is that: there is an ontological ground that there is not a conflict. But once you insist that reference and dereference are symmetric relation, it is this thesis that is heading to trouble.  
Ultimately our job here is to write specifications that will be used to implement code that works consistently between implementations and across the entire Internet.  We can't do that if what we specify conflicts with widespread existing practice. 
Right. But who is doing that?
And when we talk about using well-established protocols like http URIs or even URNs in an abstract fashion that doesn't consider the huge body of existing practice, it's hard to imagine that anything useful will come of it.
You bring another ambiguous concept -- "abstraction" -- into discussion. Again, it will be your burden of proof to clarify the distinction.

Xiaoshu
--------------070607050201020101060608-- From moore@network-heretics.com Wed Apr 28 10:58:26 2010 Return-Path: X-Original-To: urn@core3.amsl.com Delivered-To: urn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BC703A69D0 for ; Wed, 28 Apr 2010 10:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.227 X-Spam-Level: X-Spam-Status: No, score=0.227 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_50=0.001, 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 I9hJppmA7yLT for ; Wed, 28 Apr 2010 10:58:24 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id A5C693A6979 for ; Wed, 28 Apr 2010 10:58:24 -0700 (PDT) Received: from lust.indecency.org (174-151-122-31.pools.spcsdns.net [174.151.122.31]) by m1.imap-partners.net (MOS 4.1.8-GA) with ESMTP id BQY79829 (AUTH admin@network-heretics.com); Wed, 28 Apr 2010 10:58:07 -0700 X-Mirapoint-Received-SPF: 174.151.122.31 lust.indecency.org 5 none X-Mirapoint-Received-SPF: 174.151.122.31 lust.indecency.org 5 none X-Mirapoint-Received-SPF: 174.151.122.31 lust.indecency.org 5 none Message-ID: <4BD8772D.7080601@network-heretics.com> Date: Wed, 28 Apr 2010 13:58:05 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: xiao@renci.org References: <201004280802.KAA11778@TR-Sys.de> <4BD83069.6060407@gmx.de> <4BD83B51.7010100@renci.org> <4BD83F7D.1050100@network-heretics.com> <4BD845CD.4060100@renci.org> <4BD847A2.8090204@network-heretics.com> <4BD84969.9000109@renci.org> <4BD86147.3030401@network-heretics.com> <4BD863CA.3050004@renci.org> In-Reply-To: <4BD863CA.3050004@renci.org> Content-Type: multipart/alternative; boundary="------------050109090202000902020302" Cc: "urn@ietf.org" Subject: Re: [urn] fragment identifiers, Re: rfc2141bis [was: Re: A first cut at the Draft Charter ...] X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 17:58:26 -0000 This is a multi-part message in MIME format. --------------050109090202000902020302 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 4/28/10 12:35 PM, Xiaoshu Wang wrote: > On 4/28/10 12:24 PM, Keith Moore wrote: >> On 4/28/10 10:42 AM, Xiaoshu Wang wrote: >>> On 4/28/10 10:35 AM, Keith Moore wrote: >>>> On 4/28/10 10:27 AM, Xiaoshu Wang wrote: >>>>> We have to understand that what a URI references is not the same >>>>> as what is de-referenced from the URI. >>>> Well, IMO, that makes very little sense. I realize that there's a >>>> growing tendency to use URIs as pure names, or as names that don't >>>> refer specifically to a network-accessible resource - and then to >>>> say that if de-referencing the URI over the network happens to >>>> return a resource, that it's not the same thing as what is named by >>>> the URI. But neither URIs nor the other mechanisms associated with >>>> the web were designed to work this way. Trying to re-justify all >>>> of the existing notations, protocols, and other infrastructure in >>>> terms of some more abstract (and revisionist) idea of what URIs >>>> are, is silly, and has no place in an organization that purports to >>>> do engineering. >>> Well, I disagree. But what is the purpose of this URN mailing list? >>> I am not sure what you mean by "use URIs as pure names, ...". Can >>> you define: >>> >>> -- What is "a pure name"? >> This is a term we were using many years ago in the original URN >> discussions. I never saw a formal definition of the term. My best >> attempt to define a pure name would be a name that isn't bound to >> anything that exists in concrete or tangible form. If it's bound to >> anything, it's an abstract concept. It's meaningless to speak of >> de-referencing or accessing the resource associated with a pure name. > If a name is bound to nothing. It is useless. Any name is bound with a > *transportation* protocol. The names that we use in natural language > is bound to our cognitive system. A pure name, in the sense that is > not bound with any retrieval protocol, doesn't exist. URNs are not bound to any retrieval protocol. That's the entire point of URNs - to allow resources to be named independently of their location or the protocol used to access them. That doesn't mean, of course, that a URN is not bound to anything, just that it's not associated (as most URLs are) with any particular location or retrieval protocol. And just because a name isn't bound to anything that exists in concrete or tangible form, doesn't mean it's useless. We give names to ideas all the time. >>> -- What is a network-accessible resource? >> It's a resource that can be accessed using the network. If the >> resource named by http://foo.com/bar.doc is a Microsoft Word >> document, and you can download that resource from the indicated web >> site, it's a network-accessible resource. (Often the resource and >> the representation really are the same thing.) > "http://foo.com/bar.doc" can be potentially bound with an HTML > representation. What is this network-accessible resource? It's not complicated. If a resource can be accessed over the network, it's a network-accessible resource. I cited a Microsoft Word document that has only one representation just as a simple, concrete example. A resource that has multiple representations can still be network-accessible. It's just that when you make a distinction between resource and representation, you head down a slippery slope to a place where the resource exists only in abstract form and the only concrete realizations are "representations". At that ill-defined place, the "resource" is no longer network-accessible. > I can use "http://example.com/earth" to name the Earth. Is the earth > network-accessible resource? Not unless you have some way to download the Earth over the network. >>> Is knowledge engineering what all of us ultimately want to do? If >>> not, what is it? And if so, I guess that we cannot avoid these hard >>> questions. >> I can't answer that question for others. But I can confidently say >> that trying to take an extremely widely deployed architecture and >> infrastructure, and trying to redefine its behavior in a way that >> conflicts with its design and widespread use, is unlikely to be >> successful. > Who said there is a conflict? Isn't what I am trying to say is that: > there is an ontological ground that there is not a conflict. But once > you insist that reference and dereference are symmetric relation, it > is this thesis that is heading to trouble. The ontological ground might not produce a conflict in itself, but it might conflict with widespread existing practice. IETF's job is to make things work well, not to get the philosophy right. >> Ultimately our job here is to write specifications that will be used >> to implement code that works consistently between implementations and >> across the entire Internet. We can't do that if what we specify >> conflicts with widespread existing practice. > Right. But who is doing that? Well, if we talk about fragment identifiers and how they relate to base URIs, and we end up defining the behavior in such a way that it's inconsistent with existing widespread practice, it doesn't matter how clean the philosophy is - it's still broken. >> And when we talk about using well-established protocols like http >> URIs or even URNs in an abstract fashion that doesn't consider the >> huge body of existing practice, it's hard to imagine that anything >> useful will come of it. > You bring another ambiguous concept -- "abstraction" -- into > discussion. Again, it will be your burden of proof to clarify the > distinction. I beg your pardon? I don't think I have to prove anything to you about URNs. Keith --------------050109090202000902020302 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 4/28/10 12:35 PM, Xiaoshu Wang wrote:
On 4/28/10 12:24 PM, Keith Moore wrote:
On 4/28/10 10:42 AM, Xiaoshu Wang wrote:
On 4/28/10 10:35 AM, Keith Moore wrote:
On 4/28/10 10:27 AM, Xiaoshu Wang wrote:
We have to understand that what a URI references is not the same as what is de-referenced from the URI.
Well, IMO, that makes very little sense.  I realize that there's a growing tendency to use URIs as pure names, or as names that don't refer specifically to a network-accessible resource - and then to say that if de-referencing the URI over the network happens to return a resource, that it's not the same thing as what is named by the URI.  But neither URIs nor the other mechanisms associated with the web were designed to work this way.  Trying to re-justify all of the existing notations, protocols, and other infrastructure in terms of some more abstract (and revisionist) idea of what URIs are, is silly, and has no place in an organization that purports to do engineering.
Well, I disagree. But what is the purpose of this URN mailing list? I am not sure what you mean by "use URIs as pure names, ...". Can you define:

-- What is "a pure name"?
This is a term we were using many years ago in the original URN discussions.   I never saw a formal definition of the term.  My best attempt to define a pure name would be a name that isn't bound to anything that exists in concrete or tangible form.  If it's bound to anything, it's an abstract concept.   It's meaningless to speak of de-referencing or accessing the resource associated with a pure name.
If a name is bound to nothing. It is useless. Any name is bound with a *transportation* protocol. The names that we use in natural language is bound to our cognitive system. A pure name, in the sense that is not bound with any retrieval protocol, doesn't exist.
URNs are not bound to any retrieval protocol.  That's the entire point of URNs - to allow resources to be named independently of their location or the protocol used to access them.  That doesn't mean, of course, that a URN is not bound to anything, just that it's not associated (as most URLs are) with any particular location or retrieval protocol.

And just because a name isn't bound to anything that exists in concrete or tangible form, doesn't mean it's useless.   We give names to ideas all the time.
-- What is a network-accessible resource?
It's a resource that can be accessed using the network.  If the resource named by http://foo.com/bar.doc is a Microsoft Word document, and you can download that resource from the indicated web site, it's a network-accessible resource.  (Often the resource and the representation really are the same thing.)
"http://foo.com/bar.doc" can be potentially bound with an HTML representation. What is this network-accessible resource?
It's not complicated.  If a resource can be accessed over the network, it's a network-accessible resource.  

I cited a Microsoft Word document that has only one representation just as a simple, concrete example.    A resource that has multiple representations can still be network-accessible.  It's just that when you make a distinction between resource and representation, you head down a slippery slope to a place where the resource exists only in abstract form and the only concrete realizations are "representations".  At that ill-defined place, the "resource" is no longer network-accessible.
I can use "http://example.com/earth" to name the Earth. Is the earth network-accessible resource?
Not unless you have some way to download the Earth over the network.
Is knowledge engineering what all of us ultimately want to do? If not, what is it? And if so, I guess that we cannot avoid these hard questions.
I can't answer that question for others.  But I can confidently say that trying to take an extremely widely deployed architecture and infrastructure, and trying to redefine its behavior in a way that conflicts with its design and widespread use, is unlikely to be successful.  
Who said there is a conflict? Isn't what I am trying to say is that: there is an ontological ground that there is not a conflict. But once you insist that reference and dereference are symmetric relation, it is this thesis that is heading to trouble.
The ontological ground might not produce a conflict in itself, but it might conflict with widespread existing practice.   IETF's job is to make things work well, not to get the philosophy right.
Ultimately our job here is to write specifications that will be used to implement code that works consistently between implementations and across the entire Internet.  We can't do that if what we specify conflicts with widespread existing practice. 
Right. But who is doing that?
Well, if we talk about fragment identifiers and how they relate to base URIs, and we end up defining the behavior in such a way that it's inconsistent with existing widespread practice, it doesn't matter how clean the philosophy is - it's still broken. 
And when we talk about using well-established protocols like http URIs or even URNs in an abstract fashion that doesn't consider the huge body of existing practice, it's hard to imagine that anything useful will come of it.
You bring another ambiguous concept -- "abstraction" -- into discussion. Again, it will be your burden of proof to clarify the distinction.
I beg your pardon?   I don't think I have to prove anything to you about URNs.

Keith

--------------050109090202000902020302-- From xiao@renci.org Wed Apr 28 11:18:43 2010 Return-Path: X-Original-To: urn@core3.amsl.com Delivered-To: urn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46D1E3A6BFD for ; Wed, 28 Apr 2010 11:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.016 X-Spam-Level: X-Spam-Status: No, score=-0.016 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_50=0.001, 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 KN2OZlig7ayz for ; Wed, 28 Apr 2010 11:18:40 -0700 (PDT) Received: from mx1.renci.org (email.renci.org [152.54.4.63]) by core3.amsl.com (Postfix) with ESMTP id C33183A6C0E for ; Wed, 28 Apr 2010 11:18:34 -0700 (PDT) Received: from wireless152023025161.med.unc.edu (wireless152023025161.med.unc.edu [152.23.25.161]) (authenticated bits=0) by mx1.renci.org (8.14.2/8.14.2) with ESMTP id o3SIIIug020427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Apr 2010 14:18:18 -0400 Message-ID: <4BD87BEA.9070309@renci.org> Date: Wed, 28 Apr 2010 14:18:18 -0400 From: Xiaoshu Wang User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Keith Moore References: <201004280802.KAA11778@TR-Sys.de> <4BD83069.6060407@gmx.de> <4BD83B51.7010100@renci.org> <4BD83F7D.1050100@network-heretics.com> <4BD845CD.4060100@renci.org> <4BD847A2.8090204@network-heretics.com> <4BD84969.9000109@renci.org> <4BD86147.3030401@network-heretics.com> <4BD863CA.3050004@renci.org> <4BD8772D.7080601@network-heretics.com> In-Reply-To: <4BD8772D.7080601@network-heretics.com> Content-Type: multipart/alternative; boundary="------------000502040909050707010900" X-MS-Exchange-Organization-SCL: 0 X-Scanned-By: MIMEDefang 2.63 on 152.54.4.60 Cc: "urn@ietf.org" Subject: Re: [urn] fragment identifiers, Re: rfc2141bis [was: Re: A first cut at the Draft Charter ...] X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: xiao@renci.org List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 18:18:43 -0000 This is a multi-part message in MIME format. --------------000502040909050707010900 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 4/28/10 1:58 PM, Keith Moore wrote: > On 4/28/10 12:35 PM, Xiaoshu Wang wrote: >> On 4/28/10 12:24 PM, Keith Moore wrote: >>> On 4/28/10 10:42 AM, Xiaoshu Wang wrote: >>>> On 4/28/10 10:35 AM, Keith Moore wrote: >>>>> On 4/28/10 10:27 AM, Xiaoshu Wang wrote: >>>>>> We have to understand that what a URI references is not the same >>>>>> as what is de-referenced from the URI. >>>>> Well, IMO, that makes very little sense. I realize that there's a >>>>> growing tendency to use URIs as pure names, or as names that don't >>>>> refer specifically to a network-accessible resource - and then to >>>>> say that if de-referencing the URI over the network happens to >>>>> return a resource, that it's not the same thing as what is named >>>>> by the URI. But neither URIs nor the other mechanisms associated >>>>> with the web were designed to work this way. Trying to re-justify >>>>> all of the existing notations, protocols, and other infrastructure >>>>> in terms of some more abstract (and revisionist) idea of what URIs >>>>> are, is silly, and has no place in an organization that purports >>>>> to do engineering. >>>> Well, I disagree. But what is the purpose of this URN mailing list? >>>> I am not sure what you mean by "use URIs as pure names, ...". Can >>>> you define: >>>> >>>> -- What is "a pure name"? >>> This is a term we were using many years ago in the original URN >>> discussions. I never saw a formal definition of the term. My best >>> attempt to define a pure name would be a name that isn't bound to >>> anything that exists in concrete or tangible form. If it's bound to >>> anything, it's an abstract concept. It's meaningless to speak of >>> de-referencing or accessing the resource associated with a pure name. >> If a name is bound to nothing. It is useless. Any name is bound with >> a *transportation* protocol. The names that we use in natural >> language is bound to our cognitive system. A pure name, in the sense >> that is not bound with any retrieval protocol, doesn't exist. > URNs are not bound to any retrieval protocol. That's the entire point > of URNs - to allow resources to be named independently of their > location or the protocol used to access them. That doesn't mean, of > course, that a URN is not bound to anything, just that it's not > associated (as most URLs are) with any particular location or > retrieval protocol. > > And just because a name isn't bound to anything that exists in > concrete or tangible form, doesn't mean it's useless. We give names > to ideas all the time. >>>> -- What is a network-accessible resource? >>> It's a resource that can be accessed using the network. If the >>> resource named by http://foo.com/bar.doc is a Microsoft Word >>> document, and you can download that resource from the indicated web >>> site, it's a network-accessible resource. (Often the resource and >>> the representation really are the same thing.) >> "http://foo.com/bar.doc" can be potentially bound with an HTML >> representation. What is this network-accessible resource? > It's not complicated. If a resource can be accessed over the network, > it's a network-accessible resource. > > I cited a Microsoft Word document that has only one representation > just as a simple, concrete example. A resource that has multiple > representations can still be network-accessible. It's just that when > you make a distinction between resource and representation, you head > down a slippery slope to a place where the resource exists only in > abstract form and the only concrete realizations are > "representations". At that ill-defined place, the "resource" is no > longer network-accessible. This is the logic behind the so-called "information resource", which no one can give a meaningful definition yet. >> I can use "http://example.com/earth" to name the Earth. Is the earth >> network-accessible resource? > Not unless you have some way to download the Earth over the network. Again, you are implying that what a name references is the same as what is dereferenced from it. "http://example.com/earth" is a name referring to the Earth. Dereferencing it gets you a representation of the Earth, but not the Earth itself. It is the same with your "Word Document" example. You never get *the* document, even if it is a single representation of it. At most, you get a copy of it. >>>> Is knowledge engineering what all of us ultimately want to do? If >>>> not, what is it? And if so, I guess that we cannot avoid these hard >>>> questions. >>> I can't answer that question for others. But I can confidently say >>> that trying to take an extremely widely deployed architecture and >>> infrastructure, and trying to redefine its behavior in a way that >>> conflicts with its design and widespread use, is unlikely to be >>> successful. >> Who said there is a conflict? Isn't what I am trying to say is that: >> there is an ontological ground that there is not a conflict. But once >> you insist that reference and dereference are symmetric relation, it >> is this thesis that is heading to trouble. > The ontological ground might not produce a conflict in itself, but it > might conflict with widespread existing practice. IETF's job is to > make things work well, not to get the philosophy right. But isn't it because things does not work well that this URN mailing list is created? >>> Ultimately our job here is to write specifications that will be used >>> to implement code that works consistently between implementations >>> and across the entire Internet. We can't do that if what we specify >>> conflicts with widespread existing practice. >> Right. But who is doing that? > Well, if we talk about fragment identifiers and how they relate to > base URIs, and we end up defining the behavior in such a way that it's > inconsistent with existing widespread practice, it doesn't matter how > clean the philosophy is - it's still broken. So, you mean we should do things the old way, regardless if it is wrong or not? If that is the case, how science and technology advance? >>> And when we talk about using well-established protocols like http >>> URIs or even URNs in an abstract fashion that doesn't consider the >>> huge body of existing practice, it's hard to imagine that anything >>> useful will come of it. >> You bring another ambiguous concept -- "abstraction" -- into >> discussion. Again, it will be your burden of proof to clarify the >> distinction. > I beg your pardon? I don't think I have to prove anything to you > about URNs. You uses a lot of concepts, such as "abstract", "ideas", etc. in the dispute. But the truth is all these are philosophical debatable concept. My thesis is very simple: as long as we understand the asymmetry between reference and dereference, everything is clear. There is no need to bring in any other vaguely defined concepts, such as "abstraction", "information resource", and "ideas" etc. into the debate. Doing so doesn't help. It only brings more questions. Xiaoshu --------------000502040909050707010900 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 4/28/10 1:58 PM, Keith Moore wrote:
On 4/28/10 12:35 PM, Xiaoshu Wang wrote:
On 4/28/10 12:24 PM, Keith Moore wrote:
On 4/28/10 10:42 AM, Xiaoshu Wang wrote:
On 4/28/10 10:35 AM, Keith Moore wrote:
On 4/28/10 10:27 AM, Xiaoshu Wang wrote:
We have to understand that what a URI references is not the same as what is de-referenced from the URI.
Well, IMO, that makes very little sense.  I realize that there's a growing tendency to use URIs as pure names, or as names that don't refer specifically to a network-accessible resource - and then to say that if de-referencing the URI over the network happens to return a resource, that it's not the same thing as what is named by the URI.  But neither URIs nor the other mechanisms associated with the web were designed to work this way.  Trying to re-justify all of the existing notations, protocols, and other infrastructure in terms of some more abstract (and revisionist) idea of what URIs are, is silly, and has no place in an organization that purports to do engineering.
Well, I disagree. But what is the purpose of this URN mailing list? I am not sure what you mean by "use URIs as pure names, ...". Can you define:

-- What is "a pure name"?
This is a term we were using many years ago in the original URN discussions.   I never saw a formal definition of the term.  My best attempt to define a pure name would be a name that isn't bound to anything that exists in concrete or tangible form.  If it's bound to anything, it's an abstract concept.   It's meaningless to speak of de-referencing or accessing the resource associated with a pure name.
If a name is bound to nothing. It is useless. Any name is bound with a *transportation* protocol. The names that we use in natural language is bound to our cognitive system. A pure name, in the sense that is not bound with any retrieval protocol, doesn't exist.
URNs are not bound to any retrieval protocol.  That's the entire point of URNs - to allow resources to be named independently of their location or the protocol used to access them.  That doesn't mean, of course, that a URN is not bound to anything, just that it's not associated (as most URLs are) with any particular location or retrieval protocol.

And just because a name isn't bound to anything that exists in concrete or tangible form, doesn't mean it's useless.   We give names to ideas all the time.
-- What is a network-accessible resource?
It's a resource that can be accessed using the network.  If the resource named by http://foo.com/bar.doc is a Microsoft Word document, and you can download that resource from the indicated web site, it's a network-accessible resource.  (Often the resource and the representation really are the same thing.)
"http://foo.com/bar.doc" can be potentially bound with an HTML representation. What is this network-accessible resource?
It's not complicated.  If a resource can be accessed over the network, it's a network-accessible resource.  

I cited a Microsoft Word document that has only one representation just as a simple, concrete example.    A resource that has multiple representations can still be network-accessible.  It's just that when you make a distinction between resource and representation, you head down a slippery slope to a place where the resource exists only in abstract form and the only concrete realizations are "representations".  At that ill-defined place, the "resource" is no longer network-accessible.
This is the logic behind the so-called "information resource", which no one can give a meaningful definition yet.
I can use "http://example.com/earth" to name the Earth. Is the earth network-accessible resource?
Not unless you have some way to download the Earth over the network.
Again, you are implying that what a name references is the same as what is dereferenced from it. "http://example.com/earth" is a name referring to the Earth. Dereferencing it gets you a representation of the Earth, but not the Earth itself.

It is the same with your "Word Document" example. You never get *the* document, even if it is a single representation of it. At most, you get a copy of it. 
Is knowledge engineering what all of us ultimately want to do? If not, what is it? And if so, I guess that we cannot avoid these hard questions.
I can't answer that question for others.  But I can confidently say that trying to take an extremely widely deployed architecture and infrastructure, and trying to redefine its behavior in a way that conflicts with its design and widespread use, is unlikely to be successful.  
Who said there is a conflict? Isn't what I am trying to say is that: there is an ontological ground that there is not a conflict. But once you insist that reference and dereference are symmetric relation, it is this thesis that is heading to trouble.
The ontological ground might not produce a conflict in itself, but it might conflict with widespread existing practice.   IETF's job is to make things work well, not to get the philosophy right.
But isn't it because things does not work well that this URN mailing list is created?
Ultimately our job here is to write specifications that will be used to implement code that works consistently between implementations and across the entire Internet.  We can't do that if what we specify conflicts with widespread existing practice. 
Right. But who is doing that?
Well, if we talk about fragment identifiers and how they relate to base URIs, and we end up defining the behavior in such a way that it's inconsistent with existing widespread practice, it doesn't matter how clean the philosophy is - it's still broken.
So, you mean we should do things the old way, regardless if it is wrong or not? If that is the case, how science and technology advance?
And when we talk about using well-established protocols like http URIs or even URNs in an abstract fashion that doesn't consider the huge body of existing practice, it's hard to imagine that anything useful will come of it.
You bring another ambiguous concept -- "abstraction" -- into discussion. Again, it will be your burden of proof to clarify the distinction.
I beg your pardon?   I don't think I have to prove anything to you about URNs.
You uses a lot of concepts, such as "abstract", "ideas", etc. in the dispute. But the truth is all these are philosophical debatable concept. My thesis is very simple: as long as we understand the asymmetry between reference and dereference, everything is clear. There is no need to bring in any other vaguely defined concepts, such as "abstraction", "information resource", and "ideas" etc. into the debate. Doing so doesn't help. It only brings more questions.

Xiaoshu

--------------000502040909050707010900-- From moore@network-heretics.com Wed Apr 28 12:13:32 2010 Return-Path: X-Original-To: urn@core3.amsl.com Delivered-To: urn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 093E93A68B5 for ; Wed, 28 Apr 2010 12:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.195 X-Spam-Level: X-Spam-Status: No, score=0.195 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_50=0.001, 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 McKb2T3AtE2l for ; Wed, 28 Apr 2010 12:13:30 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 581183A687E for ; Wed, 28 Apr 2010 12:13:30 -0700 (PDT) Received: from lust.indecency.org (174-151-122-31.pools.spcsdns.net [174.151.122.31]) by m1.imap-partners.net (MOS 4.1.8-GA) with ESMTP id BQY94965 (AUTH admin@network-heretics.com); Wed, 28 Apr 2010 12:13:11 -0700 X-Mirapoint-Received-SPF: 174.151.122.31 lust.indecency.org 5 none X-Mirapoint-Received-SPF: 174.151.122.31 lust.indecency.org 5 none X-Mirapoint-Received-SPF: 174.151.122.31 lust.indecency.org 5 none Message-ID: <4BD888C7.5080801@network-heretics.com> Date: Wed, 28 Apr 2010 15:13:11 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: xiao@renci.org References: <201004280802.KAA11778@TR-Sys.de> <4BD83069.6060407@gmx.de> <4BD83B51.7010100@renci.org> <4BD83F7D.1050100@network-heretics.com> <4BD845CD.4060100@renci.org> <4BD847A2.8090204@network-heretics.com> <4BD84969.9000109@renci.org> <4BD86147.3030401@network-heretics.com> <4BD863CA.3050004@renci.org> <4BD8772D.7080601@network-heretics.com> <4BD87BEA.9070309@renci.org> In-Reply-To: <4BD87BEA.9070309@renci.org> Content-Type: multipart/alternative; boundary="------------010603090501000600030501" Cc: "urn@ietf.org" Subject: Re: [urn] fragment identifiers, Re: rfc2141bis [was: Re: A first cut at the Draft Charter ...] X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 19:13:32 -0000 This is a multi-part message in MIME format. --------------010603090501000600030501 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit >>> I can use "http://example.com/earth" to name the Earth. Is the earth >>> network-accessible resource? >> Not unless you have some way to download the Earth over the network. > Again, you are implying that what a name references is the same as > what is dereferenced from it. I'm saying that there is an enormous body of existing practice for which this is true, and there is a lot of dependence on this being true. e.g. in many cases when you download a file using an http: URL, what you require is not that you get some "representation" of the resource named by that URL, but an exact copy of that resource. > "http://example.com/earth" is a name referring to the Earth. > Dereferencing it gets you a representation of the Earth, but not the > Earth itself. If you coin a URI you get to decide what that URI is bound to. You get to decide whether it refers to a very specific sequence of octets, or to something a bit fuzzier. But saying that you're coining a URI for the Earth when the best you can ever hope to return is an extremely inexact representation of it, seems grossly imprecise at best, and probably not a good example on which to base a protocol engineering discussion. > It is the same with your "Word Document" example. You never get *the* > document, even if it is a single representation of it. At most, you > get a copy of it. Correct, you get an exact copy of it. And of course, the distinction between a copy of the resource and the resource pointed to by the URI is important - e.g. if you change the copy, it doesn't change the resource bound to the URI. >>>>> Is knowledge engineering what all of us ultimately want to do? If >>>>> not, what is it? And if so, I guess that we cannot avoid these >>>>> hard questions. >>>> I can't answer that question for others. But I can confidently say >>>> that trying to take an extremely widely deployed architecture and >>>> infrastructure, and trying to redefine its behavior in a way that >>>> conflicts with its design and widespread use, is unlikely to be >>>> successful. >>> Who said there is a conflict? Isn't what I am trying to say is that: >>> there is an ontological ground that there is not a conflict. But >>> once you insist that reference and dereference are symmetric >>> relation, it is this thesis that is heading to trouble. >> The ontological ground might not produce a conflict in itself, but it >> might conflict with widespread existing practice. IETF's job is to >> make things work well, not to get the philosophy right. > But isn't it because things does not work well that this URN mailing > list is created? I have yet to understand the specific reasons why this list was created, other than to clean up a few very technical ambiguities and errata in the existing URN specifications and in how they relate to other specifications. I'm not aware that these technical ambiguities or errata have caused any significant operational problems, though of course they might have. >>>> Ultimately our job here is to write specifications that will be >>>> used to implement code that works consistently between >>>> implementations and across the entire Internet. We can't do that >>>> if what we specify conflicts with widespread existing practice. >>> Right. But who is doing that? >> Well, if we talk about fragment identifiers and how they relate to >> base URIs, and we end up defining the behavior in such a way that >> it's inconsistent with existing widespread practice, it doesn't >> matter how clean the philosophy is - it's still broken. > So, you mean we should do things the old way, regardless if it is > wrong or not? If that is the case, how science and technology advance? I'm saying that the old way is not "wrong" merely because it conflicts with your (or anyone else's) philosophy. It's just different, and perhaps less useful that it might have been if it were better designed in the first place. (or perhaps not). The old way - the huge body of widespread practice - is what it is, for better or worse. We cannot retroactively change existing behavior, and we have very little power to affect the behavior of new implementations if those implementations would act contrary to current widely-expected behavior. e.g. If you don't like the old way that existing fragment identifiers work, it's too bad, you can't change it. You might be able to get someone to define a new kind of fragment identifier with a different syntax. (Though it probably wouldn't be within the scope of a new URI working group.) >>>> And when we talk about using well-established protocols like http >>>> URIs or even URNs in an abstract fashion that doesn't consider the >>>> huge body of existing practice, it's hard to imagine that anything >>>> useful will come of it. >>> You bring another ambiguous concept -- "abstraction" -- into >>> discussion. Again, it will be your burden of proof to clarify the >>> distinction. >> I beg your pardon? I don't think I have to prove anything to you >> about URNs. > You uses a lot of concepts, such as "abstract", "ideas", etc. in the > dispute. But the truth is all these are philosophical debatable > concept. My thesis is very simple: as long as we understand the > asymmetry between reference and dereference, everything is clear. Well, I think it's confusing to use "reference" to refer to the creation of a binding from a URI to a resource, and "dereference" to refer to the obtaining of a copy (or representation) of that resource given the URI. But of course these are two distinct operations. > There is no need to bring in any other vaguely defined concepts, such > as "abstraction", "information resource", and "ideas" etc. into the > debate. Doing so doesn't help. It only brings more questions. I want the discussion to be grounded in technical reality - what a URI means in terms of what you can do with it on the network, and when appropriate, what it means in terms of specific protocol interactions. And part of that technical reality is that we're mostly stuck with existing practice, even if the model isn't as ideologically pure as some of us like. Keith --------------010603090501000600030501 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
I can use "http://example.com/earth" to name the Earth. Is the earth network-accessible resource?
Not unless you have some way to download the Earth over the network.
Again, you are implying that what a name references is the same as what is dereferenced from it.
I'm saying that there is an enormous body of existing practice for which this is true, and there is a lot of dependence on this being true.

e.g. in many cases when you download a file using an http: URL, what you require is not that you get some "representation" of the resource named by that URL, but an exact copy of that resource.
"http://example.com/earth" is a name referring to the Earth. Dereferencing it gets you a representation of the Earth, but not the Earth itself.
If you coin a URI you get to decide what that URI is bound to.  You get to decide whether it refers to a very specific sequence of octets, or to something a bit fuzzier.  But saying that you're coining a URI for the Earth when the best you can ever hope to return is an extremely inexact representation of it, seems grossly imprecise at best, and probably not a good example on which to base a protocol engineering discussion.
It is the same with your "Word Document" example. You never get *the* document, even if it is a single representation of it. At most, you get a copy of it.
Correct, you get an exact copy of it.   And of course, the distinction between a copy of the resource and the resource pointed to by the URI is important - e.g. if you change the copy, it doesn't change the resource bound to the URI.
Is knowledge engineering what all of us ultimately want to do? If not, what is it? And if so, I guess that we cannot avoid these hard questions.
I can't answer that question for others.  But I can confidently say that trying to take an extremely widely deployed architecture and infrastructure, and trying to redefine its behavior in a way that conflicts with its design and widespread use, is unlikely to be successful.  
Who said there is a conflict? Isn't what I am trying to say is that: there is an ontological ground that there is not a conflict. But once you insist that reference and dereference are symmetric relation, it is this thesis that is heading to trouble.
The ontological ground might not produce a conflict in itself, but it might conflict with widespread existing practice.   IETF's job is to make things work well, not to get the philosophy right.
But isn't it because things does not work well that this URN mailing list is created?
I have yet to understand the specific reasons why this list was created, other than to clean up a few very technical ambiguities and errata in the existing URN specifications and in how they relate to other specifications.   I'm not aware that these technical ambiguities or errata have caused any significant operational problems, though of course they might have.
Ultimately our job here is to write specifications that will be used to implement code that works consistently between implementations and across the entire Internet.  We can't do that if what we specify conflicts with widespread existing practice. 
Right. But who is doing that?
Well, if we talk about fragment identifiers and how they relate to base URIs, and we end up defining the behavior in such a way that it's inconsistent with existing widespread practice, it doesn't matter how clean the philosophy is - it's still broken.
So, you mean we should do things the old way, regardless if it is wrong or not? If that is the case, how science and technology advance?
I'm saying that the old way is not "wrong" merely because it conflicts with your (or anyone else's) philosophy.  It's just different, and perhaps less useful that it might have been if it were better designed in the first place.  (or perhaps not).  The old way - the huge body of widespread practice - is what it is, for better or worse.  We cannot retroactively change existing behavior, and we have very little power to affect the behavior of new implementations if those implementations would act contrary to current widely-expected behavior.   

e.g. If you don't like the old way that existing fragment identifiers work, it's too bad, you can't change it.  You might be able to get someone to define a new kind of fragment identifier with a different syntax.  (Though it probably wouldn't be within the scope of a new URI working group.)
And when we talk about using well-established protocols like http URIs or even URNs in an abstract fashion that doesn't consider the huge body of existing practice, it's hard to imagine that anything useful will come of it.
You bring another ambiguous concept -- "abstraction" -- into discussion. Again, it will be your burden of proof to clarify the distinction.
I beg your pardon?   I don't think I have to prove anything to you about URNs.
You uses a lot of concepts, such as "abstract", "ideas", etc. in the dispute. But the truth is all these are philosophical debatable concept. My thesis is very simple: as long as we understand the asymmetry between reference and dereference, everything is clear.
Well, I think it's confusing to use "reference" to refer to the creation of a binding from a URI to a resource, and "dereference" to refer to the obtaining of a copy (or representation) of that resource given the URI.  But of course these are two distinct operations. 
There is no need to bring in any other vaguely defined concepts, such as "abstraction", "information resource", and "ideas" etc. into the debate. Doing so doesn't help. It only brings more questions.
I want the discussion to be grounded in technical reality - what a URI means in terms of what you can do with it on the network, and when appropriate, what it means in terms of specific protocol interactions.   And part of that technical reality is that we're mostly stuck with existing practice, even if the model isn't as ideologically pure as some of us like.

Keith

--------------010603090501000600030501-- From xiao@renci.org Wed Apr 28 13:38:58 2010 Return-Path: X-Original-To: urn@core3.amsl.com Delivered-To: urn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7608B28C18A for ; Wed, 28 Apr 2010 13:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 ZhVAfui2gA2v for ; Wed, 28 Apr 2010 13:38:56 -0700 (PDT) Received: from mx1.renci.org (email.renci.org [152.54.4.63]) by core3.amsl.com (Postfix) with ESMTP id A95BC28C215 for ; Wed, 28 Apr 2010 13:33:37 -0700 (PDT) Received: from Xiaoshu-MacBook-Pro.local (cpe-065-190-193-065.nc.res.rr.com [65.190.193.65]) (authenticated bits=0) by mx1.renci.org (8.14.2/8.14.2) with ESMTP id o3SKXMXn003239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Apr 2010 16:33:22 -0400 Message-ID: <4BD89B92.8000501@renci.org> Date: Wed, 28 Apr 2010 16:33:22 -0400 From: Xiaoshu Wang User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Keith Moore References: <201004280802.KAA11778@TR-Sys.de> <4BD83069.6060407@gmx.de> <4BD83B51.7010100@renci.org> <4BD83F7D.1050100@network-heretics.com> <4BD845CD.4060100@renci.org> <4BD847A2.8090204@network-heretics.com> <4BD84969.9000109@renci.org> <4BD86147.3030401@network-heretics.com> <4BD863CA.3050004@renci.org> <4BD8772D.7080601@network-heretics.com> <4BD87BEA.9070309@renci.org> <4BD888C7.5080801@network-heretics.com> In-Reply-To: <4BD888C7.5080801@network-heretics.com> Content-Type: multipart/alternative; boundary="------------060600050500090906050908" X-MS-Exchange-Organization-SCL: 2 X-Scanned-By: MIMEDefang 2.63 on 152.54.4.60 Cc: "urn@ietf.org" Subject: Re: [urn] fragment identifiers, Re: rfc2141bis [was: Re: A first cut at the Draft Charter ...] X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: xiao@renci.org List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 20:38:58 -0000 This is a multi-part message in MIME format. --------------060600050500090906050908 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 4/28/10 3:13 PM, Keith Moore wrote: > >>>> I can use "http://example.com/earth" to name the Earth. Is the >>>> earth network-accessible resource? >>> Not unless you have some way to download the Earth over the network. >> Again, you are implying that what a name references is the same as >> what is dereferenced from it. > I'm saying that there is an enormous body of existing practice for > which this is true, and there is a lot of dependence on this being true. > > e.g. in many cases when you download a file using an http: URL, what > you require is not that you get some "representation" of the resource > named by that URL, but an exact copy of that resource. It is an implicit assumption. But I do not believe that it is true or it has to be true. Such a problem never occur in other information system, such as the traditional file system because there is a one-to-one relationship. This is what I believe what HTTP protocol excels compared with any other known information systems. It mirrors the reality that we live in. An apple is not that streams of photons that strike your eyes or the smells that touches your nose. These are merely some representations of the apple. It is your cognition that makes you believe it is an apple or not. >> "http://example.com/earth" is a name referring to the Earth. >> Dereferencing it gets you a representation of the Earth, but not the >> Earth itself. > If you coin a URI you get to decide what that URI is bound to. You > get to decide whether it refers to a very specific sequence of octets, > or to something a bit fuzzier. But saying that you're coining a URI > for the Earth when the best you can ever hope to return is an > extremely inexact representation of it, seems grossly imprecise at > best, and probably not a good example on which to base a protocol > engineering discussion. Nope. Let me repeat that. A URI does not necessarily refer to a sequence of octets stream. Of course, we can make them to. But that requires more information. Again, you use some ambiguous words -- "extremely inexact", please define it. Say, http://www.w3.org, do you believe that there is an exact copy of what you see from your browser? Does it matter? The same with your Word Doc example! Exact or in-exact, what is it compared to? And by which criteria? >> It is the same with your "Word Document" example. You never get *the* >> document, even if it is a single representation of it. At most, you >> get a copy of it. > Correct, you get an exact copy of it. And of course, the distinction > between a copy of the resource and the resource pointed to by the URI > is important - e.g. if you change the copy, it doesn't change the > resource bound to the URI. >>>>>> Is knowledge engineering what all of us ultimately want to do? If >>>>>> not, what is it? And if so, I guess that we cannot avoid these >>>>>> hard questions. >>>>> I can't answer that question for others. But I can confidently >>>>> say that trying to take an extremely widely deployed architecture >>>>> and infrastructure, and trying to redefine its behavior in a way >>>>> that conflicts with its design and widespread use, is unlikely to >>>>> be successful. >>>> Who said there is a conflict? Isn't what I am trying to say is >>>> that: there is an ontological ground that there is not a conflict. >>>> But once you insist that reference and dereference are symmetric >>>> relation, it is this thesis that is heading to trouble. >>> The ontological ground might not produce a conflict in itself, but >>> it might conflict with widespread existing practice. IETF's job is >>> to make things work well, not to get the philosophy right. >> But isn't it because things does not work well that this URN mailing >> list is created? > I have yet to understand the specific reasons why this list was > created, other than to clean up a few very technical ambiguities and > errata in the existing URN specifications and in how they relate to > other specifications. I'm not aware that these technical ambiguities > or errata have caused any significant operational problems, though of > course they might have. >>>>> Ultimately our job here is to write specifications that will be >>>>> used to implement code that works consistently between >>>>> implementations and across the entire Internet. We can't do that >>>>> if what we specify conflicts with widespread existing practice. >>>> Right. But who is doing that? >>> Well, if we talk about fragment identifiers and how they relate to >>> base URIs, and we end up defining the behavior in such a way that >>> it's inconsistent with existing widespread practice, it doesn't >>> matter how clean the philosophy is - it's still broken. >> So, you mean we should do things the old way, regardless if it is >> wrong or not? If that is the case, how science and technology advance? > I'm saying that the old way is not "wrong" merely because it conflicts > with your (or anyone else's) philosophy. It's just different, and > perhaps less useful that it might have been if it were better designed > in the first place. (or perhaps not). The old way - the huge body of > widespread practice - is what it is, for better or worse. We cannot > retroactively change existing behavior, and we have very little power > to affect the behavior of new implementations if those implementations > would act contrary to current widely-expected behavior. It is not just different. It carries an implicit assumption that we take for granted. That is where the wrong lies. There isn't a problem in the past because most information system, there is a one-to-one relationship between the identifier and representation. Thus, we never bothered or dared to use those identifier to reference anything-else. > > e.g. If you don't like the old way that existing fragment identifiers > work, it's too bad, you can't change it. You might be able to get > someone to define a new kind of fragment identifier with a different > syntax. (Though it probably wouldn't be within the scope of a new URI > working group.) I think the purpose is to clarify the issue. It is to understand where or what kind of assumption that leads to the conflict. I think new URI specification (RFC 3986) makes an attempt to undistinguish URN from URL. Thus, if this group is interested in revise URN, the first purpose is to understand what a name is and its relationship to transportation protocol or URL, right? >>>>> And when we talk about using well-established protocols like http >>>>> URIs or even URNs in an abstract fashion that doesn't consider the >>>>> huge body of existing practice, it's hard to imagine that anything >>>>> useful will come of it. >>>> You bring another ambiguous concept -- "abstraction" -- into >>>> discussion. Again, it will be your burden of proof to clarify the >>>> distinction. >>> I beg your pardon? I don't think I have to prove anything to you >>> about URNs. >> You uses a lot of concepts, such as "abstract", "ideas", etc. in the >> dispute. But the truth is all these are philosophical debatable >> concept. My thesis is very simple: as long as we understand the >> asymmetry between reference and dereference, everything is clear. > Well, I think it's confusing to use "reference" to refer to the > creation of a binding from a URI to a resource, and "dereference" to > refer to the obtaining of a copy (or representation) of that resource > given the URI. But of course these are two distinct operations. What is the confusion? URI -- references --> A Resource URI -- dereferenced_to --> A Representation And Resource != Representation Isn't that simple and clear enough? >> There is no need to bring in any other vaguely defined concepts, such >> as "abstraction", "information resource", and "ideas" etc. into the >> debate. Doing so doesn't help. It only brings more questions. > I want the discussion to be grounded in technical reality - what a URI > means in terms of what you can do with it on the network, and when > appropriate, what it means in terms of specific protocol > interactions. And part of that technical reality is that we're > mostly stuck with existing practice, even if the model isn't as > ideologically pure as some of us like. Are you talking about URN or URL or just URI? As you said, URN should not be bound with any protocol or network. Then, how we should ever discuss that. If we talked about it, then there is a binding somewhere/somehow, right? Then, a URN isn't "technically" a URN. It is still a URL. On the other side, I do believe that we should have a URN. But my suggestion is that we need only one set URN but not many. And the binding should be kept in human knowledge as opposed to be defined in a protocol. I think we need a URN, which I called it schemeless URN. Take http://example.com/earth as an example. The URN should be //example.com/earth And this URN can be bound with any transportation protocol, such as HTTP, HTTPS, FTP etc., which all should lead to some representations consistent with the intension of "//example.com/earth". The purpose is to maintain the URN's stability as the Web advances while new protocols are developed. Currently, HTTP can be considered the de fault bootstrap protocol. But 100 years from now, it could be a different "de fault" protocol, yet the usage of "//example.com/earth" remains stable. Xiaoshu --------------060600050500090906050908 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 4/28/10 3:13 PM, Keith Moore wrote:

I can use "http://example.com/earth" to name the Earth. Is the earth network-accessible resource?
Not unless you have some way to download the Earth over the network.
Again, you are implying that what a name references is the same as what is dereferenced from it.
I'm saying that there is an enormous body of existing practice for which this is true, and there is a lot of dependence on this being true.

e.g. in many cases when you download a file using an http: URL, what you require is not that you get some "representation" of the resource named by that URL, but an exact copy of that resource.
It is an implicit assumption. But I do not believe that it is true or it has to be true. Such a problem never occur in other information system, such as the traditional file system because there is a one-to-one relationship. This is what I believe what HTTP protocol excels compared with any other known information systems. It mirrors the reality that we live in. An apple is not that streams of photons that strike your eyes or the smells that touches your nose.  These are merely some representations of the apple. It is your cognition that makes you believe it is an apple or not.
"http://example.com/earth" is a name referring to the Earth. Dereferencing it gets you a representation of the Earth, but not the Earth itself.
If you coin a URI you get to decide what that URI is bound to.  You get to decide whether it refers to a very specific sequence of octets, or to something a bit fuzzier.  But saying that you're coining a URI for the Earth when the best you can ever hope to return is an extremely inexact representation of it, seems grossly imprecise at best, and probably not a good example on which to base a protocol engineering discussion.
Nope. Let me repeat that. A URI does not necessarily refer to a sequence of octets stream. Of course, we can make them to. But that requires more information. Again, you use some ambiguous words -- "extremely inexact", please define it.

Say, http://www.w3.org, do you believe that there is an exact copy of what you see from your browser? Does it matter? The same with your Word Doc example! Exact or in-exact, what is it compared to? And by which criteria?

It is the same with your "Word Document" example. You never get *the* document, even if it is a single representation of it. At most, you get a copy of it.
Correct, you get an exact copy of it.   And of course, the distinction between a copy of the resource and the resource pointed to by the URI is important - e.g. if you change the copy, it doesn't change the resource bound to the URI.
Is knowledge engineering what all of us ultimately want to do? If not, what is it? And if so, I guess that we cannot avoid these hard questions.
I can't answer that question for others.  But I can confidently say that trying to take an extremely widely deployed architecture and infrastructure, and trying to redefine its behavior in a way that conflicts with its design and widespread use, is unlikely to be successful.  
Who said there is a conflict? Isn't what I am trying to say is that: there is an ontological ground that there is not a conflict. But once you insist that reference and dereference are symmetric relation, it is this thesis that is heading to trouble.
The ontological ground might not produce a conflict in itself, but it might conflict with widespread existing practice.   IETF's job is to make things work well, not to get the philosophy right.
But isn't it because things does not work well that this URN mailing list is created?
I have yet to understand the specific reasons why this list was created, other than to clean up a few very technical ambiguities and errata in the existing URN specifications and in how they relate to other specifications.   I'm not aware that these technical ambiguities or errata have caused any significant operational problems, though of course they might have.
Ultimately our job here is to write specifications that will be used to implement code that works consistently between implementations and across the entire Internet.  We can't do that if what we specify conflicts with widespread existing practice. 
Right. But who is doing that?
Well, if we talk about fragment identifiers and how they relate to base URIs, and we end up defining the behavior in such a way that it's inconsistent with existing widespread practice, it doesn't matter how clean the philosophy is - it's still broken.
So, you mean we should do things the old way, regardless if it is wrong or not? If that is the case, how science and technology advance?
I'm saying that the old way is not "wrong" merely because it conflicts with your (or anyone else's) philosophy.  It's just different, and perhaps less useful that it might have been if it were better designed in the first place.  (or perhaps not).  The old way - the huge body of widespread practice - is what it is, for better or worse.  We cannot retroactively change existing behavior, and we have very little power to affect the behavior of new implementations if those implementations would act contrary to current widely-expected behavior.   
It is not just different. It carries an implicit assumption that we take for granted. That is where the wrong lies. There isn't a problem in the past because most information system, there is a one-to-one relationship between the identifier and representation. Thus, we never bothered or dared to use those identifier to reference anything-else.

e.g. If you don't like the old way that existing fragment identifiers work, it's too bad, you can't change it.  You might be able to get someone to define a new kind of fragment identifier with a different syntax.  (Though it probably wouldn't be within the scope of a new URI working group.)
I think the purpose is to clarify the issue. It is to understand where or what kind of assumption that leads to the conflict. I think new URI specification (RFC 3986) makes an attempt to undistinguish URN from URL. Thus, if this group is interested in revise URN, the first purpose is to understand what a name is and its relationship to transportation protocol or URL, right?
And when we talk about using well-established protocols like http URIs or even URNs in an abstract fashion that doesn't consider the huge body of existing practice, it's hard to imagine that anything useful will come of it.
You bring another ambiguous concept -- "abstraction" -- into discussion. Again, it will be your burden of proof to clarify the distinction.
I beg your pardon?   I don't think I have to prove anything to you about URNs.
You uses a lot of concepts, such as "abstract", "ideas", etc. in the dispute. But the truth is all these are philosophical debatable concept. My thesis is very simple: as long as we understand the asymmetry between reference and dereference, everything is clear.
Well, I think it's confusing to use "reference" to refer to the creation of a binding from a URI to a resource, and "dereference" to refer to the obtaining of a copy (or representation) of that resource given the URI.  But of course these are two distinct operations. 
What is the confusion?
URI -- references --> A Resource
URI -- dereferenced_to --> A Representation
And Resource != Representation

Isn't that simple and clear enough?
There is no need to bring in any other vaguely defined concepts, such as "abstraction", "information resource", and "ideas" etc. into the debate. Doing so doesn't help. It only brings more questions.
I want the discussion to be grounded in technical reality - what a URI means in terms of what you can do with it on the network, and when appropriate, what it means in terms of specific protocol interactions.   And part of that technical reality is that we're mostly stuck with existing practice, even if the model isn't as ideologically pure as some of us like.
Are you talking about URN or URL or just URI? As you said, URN should not be bound with any protocol or network. Then, how we should ever discuss that. If we talked about it, then there is a binding somewhere/somehow, right? Then, a URN isn't "technically" a URN. It is still a URL.

On the other side, I do believe that we should have a URN. But my suggestion is that we need only one set URN but not many. And the binding should be kept in human knowledge as opposed to be defined in a protocol.

I think we need a URN, which I called it schemeless URN. Take http://example.com/earth as an example. The URN should be

//example.com/earth

And this URN can be bound with any transportation protocol, such as HTTP, HTTPS, FTP etc., which all should lead to some representations consistent with the intension of "//example.com/earth". The purpose is to maintain the URN's stability as the Web advances while new protocols are developed. Currently, HTTP can be considered the de fault bootstrap protocol. But 100 years from now, it could be a different "de fault" protocol, yet the usage of "//example.com/earth" remains stable.

Xiaoshu

--------------060600050500090906050908-- From moore@network-heretics.com Wed Apr 28 16:05:45 2010 Return-Path: X-Original-To: urn@core3.amsl.com Delivered-To: urn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24B983A6812 for ; Wed, 28 Apr 2010 16:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.171 X-Spam-Level: X-Spam-Status: No, score=0.171 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_50=0.001, 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 JC2zbKQ8K8Ee for ; Wed, 28 Apr 2010 16:05:43 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 6CC4D3A68BC for ; Wed, 28 Apr 2010 16:05:42 -0700 (PDT) Received: from lust.indecency.org (174-151-122-31.pools.spcsdns.net [174.151.122.31]) by m1.imap-partners.net (MOS 4.1.8-GA) with ESMTP id BQZ31327 (AUTH admin@network-heretics.com); Wed, 28 Apr 2010 16:05:23 -0700 X-Mirapoint-Received-SPF: 174.151.122.31 lust.indecency.org 5 none X-Mirapoint-Received-SPF: 174.151.122.31 lust.indecency.org 5 none X-Mirapoint-Received-SPF: 174.151.122.31 lust.indecency.org 5 none Message-ID: <4BD8BF32.7030201@network-heretics.com> Date: Wed, 28 Apr 2010 19:05:22 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: xiao@renci.org References: <201004280802.KAA11778@TR-Sys.de> <4BD83069.6060407@gmx.de> <4BD83B51.7010100@renci.org> <4BD83F7D.1050100@network-heretics.com> <4BD845CD.4060100@renci.org> <4BD847A2.8090204@network-heretics.com> <4BD84969.9000109@renci.org> <4BD86147.3030401@network-heretics.com> <4BD863CA.3050004@renci.org> <4BD8772D.7080601@network-heretics.com> <4BD87BEA.9070309@renci.org> <4BD888C7.5080801@network-heretics.com> <4BD89B92.8000501@renci.org> In-Reply-To: <4BD89B92.8000501@renci.org> Content-Type: multipart/alternative; boundary="------------030106050005030808060400" Cc: "urn@ietf.org" Subject: Re: [urn] fragment identifiers, Re: rfc2141bis [was: Re: A first cut at the Draft Charter ...] X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 23:05:45 -0000 This is a multi-part message in MIME format. --------------030106050005030808060400 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 4/28/10 4:33 PM, Xiaoshu Wang wrote: > On 4/28/10 3:13 PM, Keith Moore wrote: >> >>>>> I can use "http://example.com/earth" to name the Earth. Is the >>>>> earth network-accessible resource? >>>> Not unless you have some way to download the Earth over the network. >>> Again, you are implying that what a name references is the same as >>> what is dereferenced from it. >> I'm saying that there is an enormous body of existing practice for >> which this is true, and there is a lot of dependence on this being true. >> >> e.g. in many cases when you download a file using an http: URL, what >> you require is not that you get some "representation" of the resource >> named by that URL, but an exact copy of that resource. > It is an implicit assumption. But I do not believe that it is true or > it has to be true. For some uses of the HTTP protocol and http: URLs, it absolutely has to be true. > Such a problem never occur in other information system, such as the > traditional file system because there is a one-to-one relationship. > This is what I believe what HTTP protocol excels compared with any > other known information systems. It mirrors the reality that we live in. I don't know about your reality, but in the reality that I live in, I need for protocols to work predictably. > An apple is not that streams of photons that strike your eyes or the > smells that touches your nose. These are merely some representations > of the apple. It is your cognition that makes you believe it is an > apple or not. The intended purpose of URNs is not to name fruits. It is to name network-accessible resources. >>> "http://example.com/earth" is a name referring to the Earth. >>> Dereferencing it gets you a representation of the Earth, but not the >>> Earth itself. >> If you coin a URI you get to decide what that URI is bound to. You >> get to decide whether it refers to a very specific sequence of >> octets, or to something a bit fuzzier. But saying that you're >> coining a URI for the Earth when the best you can ever hope to return >> is an extremely inexact representation of it, seems grossly imprecise >> at best, and probably not a good example on which to base a protocol >> engineering discussion. > Nope. Let me repeat that. A URI does not necessarily refer to a > sequence of octets stream. Correct so far (except for the "Nope"), and this is consistent with what I wrote above. > Of course, we can make them to. But that requires more information. It doesn't require more explicit information. Either the origin server acts predictably or it doesn't. > Again, you use some ambiguous words -- "extremely inexact", please > define it. I'm using the words in their usual sense. > Say, http://www.w3.org, do you believe that there is an exact copy of > what you see from your browser? Does it matter? The same with your > Word Doc example! Exact or in-exact, what is it compared to? And by > which criteria? Every single day, the vast majority of the files that I download need to be exact copies of what is on the origin server. >>>>>> Ultimately our job here is to write specifications that will be >>>>>> used to implement code that works consistently between >>>>>> implementations and across the entire Internet. We can't do that >>>>>> if what we specify conflicts with widespread existing practice. >>>>> Right. But who is doing that? >>>> Well, if we talk about fragment identifiers and how they relate to >>>> base URIs, and we end up defining the behavior in such a way that >>>> it's inconsistent with existing widespread practice, it doesn't >>>> matter how clean the philosophy is - it's still broken. >>> So, you mean we should do things the old way, regardless if it is >>> wrong or not? If that is the case, how science and technology advance? >> I'm saying that the old way is not "wrong" merely because it >> conflicts with your (or anyone else's) philosophy. It's just >> different, and perhaps less useful that it might have been if it were >> better designed in the first place. (or perhaps not). The old way - >> the huge body of widespread practice - is what it is, for better or >> worse. We cannot retroactively change existing behavior, and we have >> very little power to affect the behavior of new implementations if >> those implementations would act contrary to current widely-expected >> behavior. > It is not just different. It carries an implicit assumption that we > take for granted. So make it explicit. That's fine. But don't try to change widespread existing behavior even if you don't think it works as well as it should. > That is where the wrong lies. There isn't a problem in the past > because most information system, there is a one-to-one relationship > between the identifier and representation. Thus, we never bothered or > dared to use those identifier to reference anything-else. That was, in many cases, a feature. >> e.g. If you don't like the old way that existing fragment identifiers >> work, it's too bad, you can't change it. You might be able to get >> someone to define a new kind of fragment identifier with a different >> syntax. (Though it probably wouldn't be within the scope of a new >> URI working group.) > I think the purpose is to clarify the issue. It is to understand where > or what kind of assumption that leads to the conflict. I think new URI > specification (RFC 3986) makes an attempt to undistinguish URN from > URL. Thus, if this group is interested in revise URN, the first > purpose is to understand what a name is and its relationship to > transportation protocol or URL, right? IMO, there should not be a group to "revise" URNs. At most, the group should remove ambiguities and correct errata that are present in the existing specifications. >>>>>> And when we talk about using well-established protocols like http >>>>>> URIs or even URNs in an abstract fashion that doesn't consider >>>>>> the huge body of existing practice, it's hard to imagine that >>>>>> anything useful will come of it. >>>>> You bring another ambiguous concept -- "abstraction" -- into >>>>> discussion. Again, it will be your burden of proof to clarify the >>>>> distinction. >>>> I beg your pardon? I don't think I have to prove anything to you >>>> about URNs. >>> You uses a lot of concepts, such as "abstract", "ideas", etc. in the >>> dispute. But the truth is all these are philosophical debatable >>> concept. My thesis is very simple: as long as we understand the >>> asymmetry between reference and dereference, everything is clear. >> Well, I think it's confusing to use "reference" to refer to the >> creation of a binding from a URI to a resource, and "dereference" to >> refer to the obtaining of a copy (or representation) of that resource >> given the URI. But of course these are two distinct operations. > What is the confusion? > URI -- references --> A Resource > URI -- dereferenced_to --> A Representation > And Resource != Representation > > Isn't that simple and clear enough? No, it's incorrect in lots of very subtle ways. >>> There is no need to bring in any other vaguely defined concepts, >>> such as "abstraction", "information resource", and "ideas" etc. into >>> the debate. Doing so doesn't help. It only brings more questions. >> I want the discussion to be grounded in technical reality - what a >> URI means in terms of what you can do with it on the network, and >> when appropriate, what it means in terms of specific protocol >> interactions. And part of that technical reality is that we're >> mostly stuck with existing practice, even if the model isn't as >> ideologically pure as some of us like. > Are you talking about URN or URL or just URI? I'm trying to use each term as appropriate. > As you said, URN should not be bound with any protocol or network. > Then, how we should ever discuss that. If we talked about it, then > there is a binding somewhere/somehow, right? Then, a URN isn't > "technically" a URN. It is still a URL. Of course the URN can be bound to access protocols, server addresses, etc. It's just that the binding isn't exposed in the URN itself. It's allowed to change over time. > On the other side, I do believe that we should have a URN. But my > suggestion is that we need only one set URN but not many. And the > binding should be kept in human knowledge as opposed to be defined in > a protocol. > > I think we need a URN, which I called it schemeless URN. Take > http://example.com/earth as an example. The URN should be > > //example.com/earth I strongly object to your or anyone else's efforts to change well-established standards and practice regarding URNs. Those should be entirely out of scope for this working group. Keith --------------030106050005030808060400 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 4/28/10 4:33 PM, Xiaoshu Wang wrote:
On 4/28/10 3:13 PM, Keith Moore wrote:

I can use "http://example.com/earth" to name the Earth. Is the earth network-accessible resource?
Not unless you have some way to download the Earth over the network.
Again, you are implying that what a name references is the same as what is dereferenced from it.
I'm saying that there is an enormous body of existing practice for which this is true, and there is a lot of dependence on this being true.

e.g. in many cases when you download a file using an http: URL, what you require is not that you get some "representation" of the resource named by that URL, but an exact copy of that resource.
It is an implicit assumption. But I do not believe that it is true or it has to be true.
For some uses of the HTTP protocol and http: URLs, it absolutely has to be true.
Such a problem never occur in other information system, such as the traditional file system because there is a one-to-one relationship. This is what I believe what HTTP protocol excels compared with any other known information systems. It mirrors the reality that we live in.
I don't know about your reality, but in the reality that I live in, I need for protocols to work predictably.
An apple is not that streams of photons that strike your eyes or the smells that touches your nose.  These are merely some representations of the apple. It is your cognition that makes you believe it is an apple or not.
The intended purpose of URNs is not to name fruits.  It is to name network-accessible resources.
"http://example.com/earth" is a name referring to the Earth. Dereferencing it gets you a representation of the Earth, but not the Earth itself.
If you coin a URI you get to decide what that URI is bound to.  You get to decide whether it refers to a very specific sequence of octets, or to something a bit fuzzier.  But saying that you're coining a URI for the Earth when the best you can ever hope to return is an extremely inexact representation of it, seems grossly imprecise at best, and probably not a good example on which to base a protocol engineering discussion.
Nope. Let me repeat that. A URI does not necessarily refer to a sequence of octets stream.
Correct so far (except for the "Nope"), and this is consistent with what I wrote above.
Of course, we can make them to. But that requires more information.
It doesn't require more explicit information.    Either the origin server acts predictably or it doesn't.  
Again, you use some ambiguous words -- "extremely inexact", please define it.
I'm using the words in their usual sense.
Say, http://www.w3.org, do you believe that there is an exact copy of what you see from your browser? Does it matter? The same with your Word Doc example! Exact or in-exact, what is it compared to? And by which criteria?
Every single day, the vast majority of the files that I download need to be exact copies of what is on the origin server.
Ultimately our job here is to write specifications that will be used to implement code that works consistently between implementations and across the entire Internet.  We can't do that if what we specify conflicts with widespread existing practice. 
Right. But who is doing that?
Well, if we talk about fragment identifiers and how they relate to base URIs, and we end up defining the behavior in such a way that it's inconsistent with existing widespread practice, it doesn't matter how clean the philosophy is - it's still broken.
So, you mean we should do things the old way, regardless if it is wrong or not? If that is the case, how science and technology advance?
I'm saying that the old way is not "wrong" merely because it conflicts with your (or anyone else's) philosophy.  It's just different, and perhaps less useful that it might have been if it were better designed in the first place.  (or perhaps not).  The old way - the huge body of widespread practice - is what it is, for better or worse.  We cannot retroactively change existing behavior, and we have very little power to affect the behavior of new implementations if those implementations would act contrary to current widely-expected behavior.   
It is not just different. It carries an implicit assumption that we take for granted.
So make it explicit.   That's fine.   But don't try to change widespread existing behavior even if you don't think it works as well as it should.
That is where the wrong lies. There isn't a problem in the past because most information system, there is a one-to-one relationship between the identifier and representation. Thus, we never bothered or dared to use those identifier to reference anything-else.
That was, in many cases, a feature.
e.g. If you don't like the old way that existing fragment identifiers work, it's too bad, you can't change it.  You might be able to get someone to define a new kind of fragment identifier with a different syntax.  (Though it probably wouldn't be within the scope of a new URI working group.)
I think the purpose is to clarify the issue. It is to understand where or what kind of assumption that leads to the conflict. I think new URI specification (RFC 3986) makes an attempt to undistinguish URN from URL. Thus, if this group is interested in revise URN, the first purpose is to understand what a name is and its relationship to transportation protocol or URL, right?
IMO, there should not be a group to "revise" URNs.   At most, the group should remove ambiguities and correct errata that are present in the existing specifications.
And when we talk about using well-established protocols like http URIs or even URNs in an abstract fashion that doesn't consider the huge body of existing practice, it's hard to imagine that anything useful will come of it.
You bring another ambiguous concept -- "abstraction" -- into discussion. Again, it will be your burden of proof to clarify the distinction.
I beg your pardon?   I don't think I have to prove anything to you about URNs.
You uses a lot of concepts, such as "abstract", "ideas", etc. in the dispute. But the truth is all these are philosophical debatable concept. My thesis is very simple: as long as we understand the asymmetry between reference and dereference, everything is clear.
Well, I think it's confusing to use "reference" to refer to the creation of a binding from a URI to a resource, and "dereference" to refer to the obtaining of a copy (or representation) of that resource given the URI.  But of course these are two distinct operations. 
What is the confusion?
URI -- references --> A Resource
URI -- dereferenced_to --> A Representation
And Resource != Representation

Isn't that simple and clear enough?
No, it's incorrect in lots of very subtle ways.  
There is no need to bring in any other vaguely defined concepts, such as "abstraction", "information resource", and "ideas" etc. into the debate. Doing so doesn't help. It only brings more questions.
I want the discussion to be grounded in technical reality - what a URI means in terms of what you can do with it on the network, and when appropriate, what it means in terms of specific protocol interactions.   And part of that technical reality is that we're mostly stuck with existing practice, even if the model isn't as ideologically pure as some of us like.
Are you talking about URN or URL or just URI?
I'm trying to use each term as appropriate.
As you said, URN should not be bound with any protocol or network. Then, how we should ever discuss that. If we talked about it, then there is a binding somewhere/somehow, right? Then, a URN isn't "technically" a URN. It is still a URL.
Of course the URN can be bound to access protocols, server addresses, etc.   It's just that the binding isn't exposed in the URN itself.  It's allowed to change over time.
On the other side, I do believe that we should have a URN. But my suggestion is that we need only one set URN but not many. And the binding should be kept in human knowledge as opposed to be defined in a protocol.

I think we need a URN, which I called it schemeless URN. Take http://example.com/earth as an example. The URN should be

//example.com/earth
I strongly object to your or anyone else's efforts to change well-established standards and practice regarding URNs.   Those should be entirely out of scope for this working group. 

Keith

--------------030106050005030808060400-- From xiao@renci.org Wed Apr 28 16:56:18 2010 Return-Path: X-Original-To: urn@core3.amsl.com Delivered-To: urn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0643C28C0CF for ; Wed, 28 Apr 2010 16:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 C0Oc+-h12xqg for ; Wed, 28 Apr 2010 16:56:15 -0700 (PDT) Received: from mx1.renci.org (email.renci.org [152.54.4.63]) by core3.amsl.com (Postfix) with ESMTP id 877513A66B4 for ; Wed, 28 Apr 2010 16:56:15 -0700 (PDT) Received: from Xiaoshu-MacBook-Pro.local (cpe-065-190-193-065.nc.res.rr.com [65.190.193.65]) (authenticated bits=0) by mx1.renci.org (8.14.2/8.14.2) with ESMTP id o3SNu05N017877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Apr 2010 19:56:00 -0400 Message-ID: <4BD8CB0F.5030602@renci.org> Date: Wed, 28 Apr 2010 19:55:59 -0400 From: Xiaoshu Wang User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Keith Moore References: <201004280802.KAA11778@TR-Sys.de> <4BD83069.6060407@gmx.de> <4BD83B51.7010100@renci.org> <4BD83F7D.1050100@network-heretics.com> <4BD845CD.4060100@renci.org> <4BD847A2.8090204@network-heretics.com> <4BD84969.9000109@renci.org> <4BD86147.3030401@network-heretics.com> <4BD863CA.3050004@renci.org> <4BD8772D.7080601@network-heretics.com> <4BD87BEA.9070309@renci.org> <4BD888C7.5080801@network-heretics.com> <4BD89B92.8000501@renci.org> <4BD8BF32.7030201@network-heretics.com> In-Reply-To: <4BD8BF32.7030201@network-heretics.com> Content-Type: multipart/alternative; boundary="------------050201040609060903000206" X-MS-Exchange-Organization-SCL: 2 X-Scanned-By: MIMEDefang 2.63 on 152.54.4.60 Cc: "urn@ietf.org" Subject: Re: [urn] fragment identifiers, Re: rfc2141bis [was: Re: A first cut at the Draft Charter ...] X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: xiao@renci.org List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 23:56:18 -0000 This is a multi-part message in MIME format. --------------050201040609060903000206 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 4/28/10 7:05 PM, Keith Moore wrote: > On 4/28/10 4:33 PM, Xiaoshu Wang wrote: >> On 4/28/10 3:13 PM, Keith Moore wrote: >>> >>>>>> I can use "http://example.com/earth" to name the Earth. Is the >>>>>> earth network-accessible resource? >>>>> Not unless you have some way to download the Earth over the network. >>>> Again, you are implying that what a name references is the same as >>>> what is dereferenced from it. >>> I'm saying that there is an enormous body of existing practice for >>> which this is true, and there is a lot of dependence on this being true. >>> >>> e.g. in many cases when you download a file using an http: URL, what >>> you require is not that you get some "representation" of the >>> resource named by that URL, but an exact copy of that resource. >> It is an implicit assumption. But I do not believe that it is true or >> it has to be true. > For some uses of the HTTP protocol and http: URLs, it absolutely has > to be true. Really? Show me an example that if they do not take that assumption, it will fail. >> Such a problem never occur in other information system, such as the >> traditional file system because there is a one-to-one relationship. >> This is what I believe what HTTP protocol excels compared with any >> other known information systems. It mirrors the reality that we live in. > I don't know about your reality, but in the reality that I live in, I > need for protocols to work predictably. >> An apple is not that streams of photons that strike your eyes or the >> smells that touches your nose. These are merely some representations >> of the apple. It is your cognition that makes you believe it is an >> apple or not. > The intended purpose of URNs is not to name fruits. It is to name > network-accessible resources. Most people that I work with, they want names for genes, proteins, molecules, diseases, etc. But again, these can be network-accessible resources as you have not given me a definition that I can tell one from others. >>>> "http://example.com/earth" is a name referring to the Earth. >>>> Dereferencing it gets you a representation of the Earth, but not >>>> the Earth itself. >>> If you coin a URI you get to decide what that URI is bound to. You >>> get to decide whether it refers to a very specific sequence of >>> octets, or to something a bit fuzzier. But saying that you're >>> coining a URI for the Earth when the best you can ever hope to >>> return is an extremely inexact representation of it, seems grossly >>> imprecise at best, and probably not a good example on which to base >>> a protocol engineering discussion. >> Nope. Let me repeat that. A URI does not necessarily refer to a >> sequence of octets stream. > Correct so far (except for the "Nope"), and this is consistent with > what I wrote above. >> Of course, we can make them to. But that requires more information. > It doesn't require more explicit information. Either the origin > server acts predictably or it doesn't. Predictably with regard of what? If "http://example.com/aThing" names a thing, what do you expect it to be? How do you measure this predictability? Thus, getting back your early question, how do you measure failure? Please explicit your criteria. >> Again, you use some ambiguous words -- "extremely inexact", please >> define it. > I'm using the words in their usual sense. That is what you mean a technical definition? >> Say, http://www.w3.org, do you believe that there is an exact copy of >> what you see from your browser? Does it matter? The same with your >> Word Doc example! Exact or in-exact, what is it compared to? And by >> which criteria? > Every single day, the vast majority of the files that I download need > to be exact copies of what is on the origin server. Is Resources == Files? What is that you downloaded? Resource or Representation? >>>>>>> Ultimately our job here is to write specifications that will be >>>>>>> used to implement code that works consistently between >>>>>>> implementations and across the entire Internet. We can't do >>>>>>> that if what we specify conflicts with widespread existing >>>>>>> practice. >>>>>> Right. But who is doing that? >>>>> Well, if we talk about fragment identifiers and how they relate to >>>>> base URIs, and we end up defining the behavior in such a way that >>>>> it's inconsistent with existing widespread practice, it doesn't >>>>> matter how clean the philosophy is - it's still broken. >>>> So, you mean we should do things the old way, regardless if it is >>>> wrong or not? If that is the case, how science and technology advance? >>> I'm saying that the old way is not "wrong" merely because it >>> conflicts with your (or anyone else's) philosophy. It's just >>> different, and perhaps less useful that it might have been if it >>> were better designed in the first place. (or perhaps not). The old >>> way - the huge body of widespread practice - is what it is, for >>> better or worse. We cannot retroactively change existing behavior, >>> and we have very little power to affect the behavior of new >>> implementations if those implementations would act contrary to >>> current widely-expected behavior. >> It is not just different. It carries an implicit assumption that we >> take for granted. > So make it explicit. That's fine. But don't try to change > widespread existing behavior even if you don't think it works as well > as it should. What is the widespread existing behavior that any of these will change? First, I don't think there is anything that will be changed. It just makes people to think/describe things more clearly. Second, even if it requires changes, if it is for a better world, why not? >> That is where the wrong lies. There isn't a problem in the past >> because most information system, there is a one-to-one relationship >> between the identifier and representation. Thus, we never bothered or >> dared to use those identifier to reference anything-else. > That was, in many cases, a feature. A feature of ? >>> e.g. If you don't like the old way that existing fragment >>> identifiers work, it's too bad, you can't change it. You might be >>> able to get someone to define a new kind of fragment identifier with >>> a different syntax. (Though it probably wouldn't be within the >>> scope of a new URI working group.) >> I think the purpose is to clarify the issue. It is to understand >> where or what kind of assumption that leads to the conflict. I think >> new URI specification (RFC 3986) makes an attempt to undistinguish >> URN from URL. Thus, if this group is interested in revise URN, the >> first purpose is to understand what a name is and its relationship to >> transportation protocol or URL, right? > IMO, there should not be a group to "revise" URNs. At most, the > group should remove ambiguities and correct errata that are present in > the existing specifications. Then, what is the errata? >>>>>>> And when we talk about using well-established protocols like >>>>>>> http URIs or even URNs in an abstract fashion that doesn't >>>>>>> consider the huge body of existing practice, it's hard to >>>>>>> imagine that anything useful will come of it. >>>>>> You bring another ambiguous concept -- "abstraction" -- into >>>>>> discussion. Again, it will be your burden of proof to clarify the >>>>>> distinction. >>>>> I beg your pardon? I don't think I have to prove anything to you >>>>> about URNs. >>>> You uses a lot of concepts, such as "abstract", "ideas", etc. in >>>> the dispute. But the truth is all these are philosophical debatable >>>> concept. My thesis is very simple: as long as we understand the >>>> asymmetry between reference and dereference, everything is clear. >>> Well, I think it's confusing to use "reference" to refer to the >>> creation of a binding from a URI to a resource, and "dereference" to >>> refer to the obtaining of a copy (or representation) of that >>> resource given the URI. But of course these are two distinct >>> operations. >> What is the confusion? >> URI -- references --> A Resource >> URI -- dereferenced_to --> A Representation >> And Resource != Representation >> >> Isn't that simple and clear enough? > No, it's incorrect in lots of very subtle ways. Tell me where it is wrong. The reverse would be: dereference = reference or Resource = Representation. If this is your plea, you will have a very huge gap to bridge -- The DeCartian Gap. >>>> There is no need to bring in any other vaguely defined concepts, >>>> such as "abstraction", "information resource", and "ideas" etc. >>>> into the debate. Doing so doesn't help. It only brings more questions. >>> I want the discussion to be grounded in technical reality - what a >>> URI means in terms of what you can do with it on the network, and >>> when appropriate, what it means in terms of specific protocol >>> interactions. And part of that technical reality is that we're >>> mostly stuck with existing practice, even if the model isn't as >>> ideologically pure as some of us like. >> Are you talking about URN or URL or just URI? > I'm trying to use each term as appropriate. >> As you said, URN should not be bound with any protocol or network. >> Then, how we should ever discuss that. If we talked about it, then >> there is a binding somewhere/somehow, right? Then, a URN isn't >> "technically" a URN. It is still a URL. > Of course the URN can be bound to access protocols, server addresses, > etc. It's just that the binding isn't exposed in the URN itself. > It's allowed to change over time. Does it really matter if the protocol is exposed in URN or not? Have we ever prefixed a file-path with anything? But is file name is locator or name or identifier? >> On the other side, I do believe that we should have a URN. But my >> suggestion is that we need only one set URN but not many. And the >> binding should be kept in human knowledge as opposed to be defined in >> a protocol. >> >> I think we need a URN, which I called it schemeless URN. Take >> http://example.com/earth as an example. The URN should be >> >> //example.com/earth > I strongly object to your or anyone else's efforts to change > well-established standards and practice regarding URNs. Those should > be entirely out of scope for this working group. I didn't want to change anything. I think the new URI spec is good to not make a distinction between URN and URL. What I mean is if we need a URN, we should only define only one set of URN and to make it a name, do not bind it (i.e., a via specification) with any transportation protocol. That would make it a pure (technically) name. Otherwise, as long as a specification is defined to bind a particularly schemed URN to some transportation protocol, then it is no different from a URL. Or, if no binding whatsoever, the name is practically useless. It is as simple as that. Xiaoshu --------------050201040609060903000206 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 4/28/10 7:05 PM, Keith Moore wrote:
On 4/28/10 4:33 PM, Xiaoshu Wang wrote:
On 4/28/10 3:13 PM, Keith Moore wrote:

I can use "http://example.com/earth" to name the Earth. Is the earth network-accessible resource?
Not unless you have some way to download the Earth over the network.
Again, you are implying that what a name references is the same as what is dereferenced from it.
I'm saying that there is an enormous body of existing practice for which this is true, and there is a lot of dependence on this being true.

e.g. in many cases when you download a file using an http: URL, what you require is not that you get some "representation" of the resource named by that URL, but an exact copy of that resource.
It is an implicit assumption. But I do not believe that it is true or it has to be true.
For some uses of the HTTP protocol and http: URLs, it absolutely has to be true.
Really? Show me an example that if they do not take that assumption, it will fail.
Such a problem never occur in other information system, such as the traditional file system because there is a one-to-one relationship. This is what I believe what HTTP protocol excels compared with any other known information systems. It mirrors the reality that we live in.
I don't know about your reality, but in the reality that I live in, I need for protocols to work predictably.
An apple is not that streams of photons that strike your eyes or the smells that touches your nose.  These are merely some representations of the apple. It is your cognition that makes you believe it is an apple or not.
The intended purpose of URNs is not to name fruits.  It is to name network-accessible resources.
Most people that I work with, they want names for genes, proteins, molecules, diseases, etc. But again, these can be network-accessible resources as you have not given me a definition that I can tell one from others.
"http://example.com/earth" is a name referring to the Earth. Dereferencing it gets you a representation of the Earth, but not the Earth itself.
If you coin a URI you get to decide what that URI is bound to.  You get to decide whether it refers to a very specific sequence of octets, or to something a bit fuzzier.  But saying that you're coining a URI for the Earth when the best you can ever hope to return is an extremely inexact representation of it, seems grossly imprecise at best, and probably not a good example on which to base a protocol engineering discussion.
Nope. Let me repeat that. A URI does not necessarily refer to a sequence of octets stream.
Correct so far (except for the "Nope"), and this is consistent with what I wrote above.
Of course, we can make them to. But that requires more information.
It doesn't require more explicit information.    Either the origin server acts predictably or it doesn't.  
Predictably with regard of what? If "http://example.com/aThing" names a thing, what do you expect it to be? How do you measure this predictability? Thus, getting back your early question, how do you measure failure? Please explicit your criteria.
Again, you use some ambiguous words -- "extremely inexact", please define it.
I'm using the words in their usual sense.
That is what you mean a technical definition?
Say, http://www.w3.org, do you believe that there is an exact copy of what you see from your browser? Does it matter? The same with your Word Doc example! Exact or in-exact, what is it compared to? And by which criteria?
Every single day, the vast majority of the files that I download need to be exact copies of what is on the origin server.
Is Resources == Files? What is that you downloaded? Resource or Representation?
Ultimately our job here is to write specifications that will be used to implement code that works consistently between implementations and across the entire Internet.  We can't do that if what we specify conflicts with widespread existing practice. 
Right. But who is doing that?
Well, if we talk about fragment identifiers and how they relate to base URIs, and we end up defining the behavior in such a way that it's inconsistent with existing widespread practice, it doesn't matter how clean the philosophy is - it's still broken.
So, you mean we should do things the old way, regardless if it is wrong or not? If that is the case, how science and technology advance?
I'm saying that the old way is not "wrong" merely because it conflicts with your (or anyone else's) philosophy.  It's just different, and perhaps less useful that it might have been if it were better designed in the first place.  (or perhaps not).  The old way - the huge body of widespread practice - is what it is, for better or worse.  We cannot retroactively change existing behavior, and we have very little power to affect the behavior of new implementations if those implementations would act contrary to current widely-expected behavior.   
It is not just different. It carries an implicit assumption that we take for granted.
So make it explicit.   That's fine.   But don't try to change widespread existing behavior even if you don't think it works as well as it should.
What is the widespread existing behavior that any of these will change? First, I don't think there is anything that will be changed. It just makes people to think/describe things more clearly. Second, even if it requires changes, if it is for a better world, why not?
That is where the wrong lies. There isn't a problem in the past because most information system, there is a one-to-one relationship between the identifier and representation. Thus, we never bothered or dared to use those identifier to reference anything-else.
That was, in many cases, a feature.
A feature of ?
e.g. If you don't like the old way that existing fragment identifiers work, it's too bad, you can't change it.  You might be able to get someone to define a new kind of fragment identifier with a different syntax.  (Though it probably wouldn't be within the scope of a new URI working group.)
I think the purpose is to clarify the issue. It is to understand where or what kind of assumption that leads to the conflict. I think new URI specification (RFC 3986) makes an attempt to undistinguish URN from URL. Thus, if this group is interested in revise URN, the first purpose is to understand what a name is and its relationship to transportation protocol or URL, right?
IMO, there should not be a group to "revise" URNs.   At most, the group should remove ambiguities and correct errata that are present in the existing specifications.
Then, what is the errata?
And when we talk about using well-established protocols like http URIs or even URNs in an abstract fashion that doesn't consider the huge body of existing practice, it's hard to imagine that anything useful will come of it.
You bring another ambiguous concept -- "abstraction" -- into discussion. Again, it will be your burden of proof to clarify the distinction.
I beg your pardon?   I don't think I have to prove anything to you about URNs.
You uses a lot of concepts, such as "abstract", "ideas", etc. in the dispute. But the truth is all these are philosophical debatable concept. My thesis is very simple: as long as we understand the asymmetry between reference and dereference, everything is clear.
Well, I think it's confusing to use "reference" to refer to the creation of a binding from a URI to a resource, and "dereference" to refer to the obtaining of a copy (or representation) of that resource given the URI.  But of course these are two distinct operations. 
What is the confusion?
URI -- references --> A Resource
URI -- dereferenced_to --> A Representation
And Resource != Representation

Isn't that simple and clear enough?
No, it's incorrect in lots of very subtle ways.
Tell me where it is wrong. The reverse would be: dereference = reference or Resource = Representation. If this is your plea, you will have a very huge gap to bridge -- The DeCartian Gap.
There is no need to bring in any other vaguely defined concepts, such as "abstraction", "information resource", and "ideas" etc. into the debate. Doing so doesn't help. It only brings more questions.
I want the discussion to be grounded in technical reality - what a URI means in terms of what you can do with it on the network, and when appropriate, what it means in terms of specific protocol interactions.   And part of that technical reality is that we're mostly stuck with existing practice, even if the model isn't as ideologically pure as some of us like.
Are you talking about URN or URL or just URI?
I'm trying to use each term as appropriate.
As you said, URN should not be bound with any protocol or network. Then, how we should ever discuss that. If we talked about it, then there is a binding somewhere/somehow, right? Then, a URN isn't "technically" a URN. It is still a URL.
Of course the URN can be bound to access protocols, server addresses, etc.   It's just that the binding isn't exposed in the URN itself.  It's allowed to change over time.
Does it really matter if the protocol is exposed in URN or not? Have we ever prefixed a file-path with anything? But is file name is locator or name or identifier?
On the other side, I do believe that we should have a URN. But my suggestion is that we need only one set URN but not many. And the binding should be kept in human knowledge as opposed to be defined in a protocol.

I think we need a URN, which I called it schemeless URN. Take http://example.com/earth as an example. The URN should be

//example.com/earth
I strongly object to your or anyone else's efforts to change well-established standards and practice regarding URNs.   Those should be entirely out of scope for this working group. 
I didn't want to change anything. I think the new URI spec is good to not make a distinction between URN and URL. What I mean is if we need a URN, we should only define only one set of URN and to make it a name, do not bind it (i.e., a via specification) with any transportation protocol. That would make it a pure (technically) name.

Otherwise, as long as a specification is defined to bind a particularly schemed URN to some transportation protocol, then it is no different from a URL. Or, if no binding whatsoever, the name is practically useless.  It is as simple as that.

Xiaoshu
--------------050201040609060903000206-- From ted.ietf@gmail.com Wed Apr 28 17:52:36 2010 Return-Path: X-Original-To: urn@core3.amsl.com Delivered-To: urn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9882A3A67EB for ; Wed, 28 Apr 2010 17:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.124 X-Spam-Level: X-Spam-Status: No, score=-0.124 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gsh5fdDW7lOt for ; Wed, 28 Apr 2010 17:52:34 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id D49533A68F1 for ; Wed, 28 Apr 2010 17:52:33 -0700 (PDT) Received: by vws13 with SMTP id 13so856159vws.31 for ; Wed, 28 Apr 2010 17:52:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=xuODOCZrAKC40sfvEeNL6diyK1C82WUGs2Y+Bd7qnAw=; b=w5euzt+WQiToQaKQh4001WjNVN4e/XIVI/N9Ufu8ouN3rDis9QMswwSkDv50EnEDiY 2AocMTpaA4wg32XDXKoQ1o0S855RUlPD75XOI8A2P7seDKCxWsfyzqS8k97DMFqTUny+ 3sMtCmAxCDDtbho9a8By/k9c2MGpL3jDB6I2c= 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=v1fWDaAJgWvqtwHxEV6myfcBpBaLX/xh0Q+nMEdVtL9i+Pw/KxuAVm1ing/JpGnXtd rnpjKHH/hAkupya6+8LaI4S5eCUru//FwlJIQRaQFLvQc0cnYy/UoUNBs/4t5Mhl9JyV DBRo7oZ7rW1Uvrlm8ntBZkd7S/3KnBwifCKDc= MIME-Version: 1.0 Received: by 10.220.108.227 with SMTP id g35mr6020245vcp.64.1272502338064; Wed, 28 Apr 2010 17:52:18 -0700 (PDT) Received: by 10.220.77.211 with HTTP; Wed, 28 Apr 2010 17:52:17 -0700 (PDT) In-Reply-To: <4BD8CB0F.5030602@renci.org> References: <201004280802.KAA11778@TR-Sys.de> <4BD84969.9000109@renci.org> <4BD86147.3030401@network-heretics.com> <4BD863CA.3050004@renci.org> <4BD8772D.7080601@network-heretics.com> <4BD87BEA.9070309@renci.org> <4BD888C7.5080801@network-heretics.com> <4BD89B92.8000501@renci.org> <4BD8BF32.7030201@network-heretics.com> <4BD8CB0F.5030602@renci.org> Date: Wed, 28 Apr 2010 17:52:17 -0700 Message-ID: From: Ted Hardie To: xiao@renci.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "urn@ietf.org" , Keith Moore Subject: Re: [urn] fragment identifiers, Re: rfc2141bis [was: Re: A first cut at the Draft Charter ...] X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 00:52:36 -0000 Howdy, This is top posted, rather than in-line because it is a meta point. The text of RFC 2141 includes this: Uniform Resource Names (URNs) are intended to serve as persistent, location-independent, resource identifiers and are designed to make it easy to map other namespaces (which share the properties of URNs) into URN-space. The mechanism used to signal that something is a URN (and therefore is intended to have these properties) is to use the URN scheme and a namespace identifier, which in turn indicates how those properties are achieved (commonly with an organization managing the namespace). If there are other properties desired, other URI schemes may be more appropriate choices. There are 40 defined URN namsepaces in use now, and the principle of least surprise says that we need to make sure any changes this group might make to the documents does not violate the expectations on which they have built their systems. You might note, for example, that the XMPP namespaces that use URNs include at least one with a fragment identifier: http://xmpp.org/registrar/namespaces.html While we might include information for namespace authorities about how best to use these, taking the tack now that they are not permitted is inappropriate because it would violate the persistence principle inherent in URNs. Generalizing that a bit, I suspect that a group working on URN-related docu= ments can update the language and BNF and can make sure the registration procedur= es are clear, but it has to have limited scope. Any basic change to syntax or semantics has the potential for impact on the namespaces already in use; anything that does that has to be a non-starter because of the need to main= tain a consistency. Just my take on it, of course. regards, Ted Hardie On Wed, Apr 28, 2010 at 4:55 PM, Xiaoshu Wang wrote: > On 4/28/10 7:05 PM, Keith Moore wrote: > > On 4/28/10 4:33 PM, Xiaoshu Wang wrote: > > On 4/28/10 3:13 PM, Keith Moore wrote: > > I can use "http://example.com/earth" to name the Earth. Is the earth > network-accessible resource? > > Not unless you have some way to download the Earth over the network. > > Again, you are implying that what a name references is the same as what i= s > dereferenced from it. > > I'm saying that there is an enormous body of existing practice for which > this is true, and there is a lot of dependence on this being true. > > e.g. in many cases when you download a file using an http: URL, what you > require is not that you get some "representation" of the resource named b= y > that URL, but an exact copy of that resource. > > It is an implicit assumption. But I do not believe that it is true or it = has > to be true. > > For some uses of the HTTP protocol and http: URLs, it absolutely has to b= e > true. > > Really? Show me an example that if they do not take that assumption, it w= ill > fail. > > Such a problem never occur in other information system, such as the > traditional file system because there is a one-to-one relationship. This = is > what I believe what HTTP protocol excels compared with any other known > information systems. It mirrors the reality that we live in. > > I don't know about your reality, but in the reality that I live in, I nee= d > for protocols to work predictably. > > An apple is not that streams of photons that strike your eyes or the smel= ls > that touches your nose.=A0 These are merely some representations of the a= pple. > It is your cognition that makes you believe it is an apple or not. > > The intended purpose of URNs is not to name fruits.=A0 It is to name > network-accessible resources. > > Most people that I work with, they want names for genes, proteins, > molecules, diseases, etc. But again, these can be network-accessible > resources as you have not given me a definition that I can tell one from > others. > > "http://example.com/earth" is a name referring to the Earth. Dereferencin= g > it gets you a representation of the Earth, but not the Earth itself. > > If you coin a URI you get to decide what that URI is bound to.=A0 You get= to > decide whether it refers to a very specific sequence of octets, or to > something a bit fuzzier.=A0 But saying that you're coining a URI for the = Earth > when the best you can ever hope to return is an extremely inexact > representation of it, seems grossly imprecise at best, and probably not a > good example on which to base a protocol engineering discussion. > > Nope. Let me repeat that. A URI does not necessarily refer to a sequence = of > octets stream. > > Correct so far (except for the "Nope"), and this is consistent with what = I > wrote above. > > Of course, we can make them to. But that requires more information. > > It doesn't require more explicit information.=A0=A0=A0 Either the origin = server > acts predictably or it doesn't. > > Predictably with regard of what? If "http://example.com/aThing" names a > thing, what do you expect it to be? How do you measure this predictabilit= y? > Thus, getting back your early question, how do you measure failure? Pleas= e > explicit your criteria. > > Again, you use some ambiguous words -- "extremely inexact", please define > it. > > I'm using the words in their usual sense. > > That is what you mean a technical definition? > > Say, http://www.w3.org, do you believe that there is an exact copy of wha= t > you see from your browser? Does it matter? The same with your Word Doc > example! Exact or in-exact, what is it compared to? And by which criteria= ? > > Every single day, the vast majority of the files that I download need to = be > exact copies of what is on the origin server. > > Is Resources =3D=3D Files? What is that you downloaded? Resource or > Representation? > > Ultimately our job here is to write specifications that will be used to > implement code that works consistently between implementations and across > the entire Internet.=A0 We can't do that if what we specify conflicts wit= h > widespread existing practice. > > Right. But who is doing that? > > Well, if we talk about fragment identifiers and how they relate to base > URIs, and we end up defining the behavior in such a way that it's > inconsistent with existing widespread practice, it doesn't matter how cle= an > the philosophy is - it's still broken. > > So, you mean we should do things the old way, regardless if it is wrong o= r > not? If that is the case, how science and technology advance? > > I'm saying that the old way is not "wrong" merely because it conflicts wi= th > your (or anyone else's) philosophy.=A0 It's just different, and perhaps l= ess > useful that it might have been if it were better designed in the first > place.=A0 (or perhaps not).=A0 The old way - the huge body of widespread > practice - is what it is, for better or worse.=A0 We cannot retroactively > change existing behavior, and we have very little power to affect the > behavior of new implementations if those implementations would act contra= ry > to current widely-expected behavior. > > It is not just different. It carries an implicit assumption that we take = for > granted. > > So make it explicit.=A0=A0 That's fine.=A0=A0 But don't try to change wid= espread > existing behavior even if you don't think it works as well as it should. > > What is the widespread existing behavior that any of these will change? > First, I don't think there is anything that will be changed. It just make= s > people to think/describe things more clearly. Second, even if it requires > changes, if it is for a better world, why not? > > That is where the wrong lies. There isn't a problem in the past because m= ost > information system, there is a one-to-one relationship between the > identifier and representation. Thus, we never bothered or dared to use th= ose > identifier to reference anything-else. > > That was, in many cases, a feature. > > A feature of ? > > e.g. If you don't like the old way that existing fragment identifiers wor= k, > it's too bad, you can't change it.=A0 You might be able to get someone to > define a new kind of fragment identifier with a different syntax.=A0 (Tho= ugh > it probably wouldn't be within the scope of a new URI working group.) > > I think the purpose is to clarify the issue. It is to understand where or > what kind of assumption that leads to the conflict. I think new URI > specification (RFC 3986) makes an attempt to undistinguish URN from URL. > Thus, if this group is interested in revise URN, the first purpose is to > understand what a name is and its relationship to transportation protocol= or > URL, right? > > IMO, there should not be a group to "revise" URNs.=A0=A0 At most, the gro= up > should remove ambiguities and correct errata that are present in the > existing specifications. > > Then, what is the errata? > > And when we talk about using well-established protocols like http URIs or > even URNs in an abstract fashion that doesn't consider the huge body of > existing practice, it's hard to imagine that anything useful will come of > it. > > You bring another ambiguous concept -- "abstraction" -- into discussion. > Again, it will be your burden of proof to clarify the distinction. > > I beg your pardon?=A0=A0 I don't think I have to prove anything to you ab= out > URNs. > > You uses a lot of concepts, such as "abstract", "ideas", etc. in the > dispute. But the truth is all these are philosophical debatable concept. = My > thesis is very simple: as long as we understand the asymmetry between > reference and dereference, everything is clear. > > Well, I think it's confusing to use "reference" to refer to the creation = of > a binding from a URI to a resource, and "dereference" to refer to the > obtaining of a copy (or representation) of that resource given the URI.= =A0 But > of course these are two distinct operations. > > What is the confusion? > URI -- references --> A Resource > URI -- dereferenced_to --> A Representation > And Resource !=3D Representation > > Isn't that simple and clear enough? > > No, it's incorrect in lots of very subtle ways. > > Tell me where it is wrong. The reverse would be: dereference =3D referenc= e or > Resource =3D Representation. If this is your plea, you will have a very h= uge > gap to bridge -- The DeCartian Gap. > > There is no need to bring in any other vaguely defined concepts, such as > "abstraction", "information resource", and "ideas" etc. into the debate. > Doing so doesn't help. It only brings more questions. > > I want the discussion to be grounded in technical reality - what a URI me= ans > in terms of what you can do with it on the network, and when appropriate, > what it means in terms of specific protocol interactions.=A0=A0 And part = of that > technical reality is that we're mostly stuck with existing practice, even= if > the model isn't as ideologically pure as some of us like. > > Are you talking about URN or URL or just URI? > > I'm trying to use each term as appropriate. > > As you said, URN should not be bound with any protocol or network. Then, = how > we should ever discuss that. If we talked about it, then there is a bindi= ng > somewhere/somehow, right? Then, a URN isn't "technically" a URN. It is st= ill > a URL. > > Of course the URN can be bound to access protocols, server addresses, etc= . > It's just that the binding isn't exposed in the URN itself.=A0 It's allow= ed to > change over time. > > Does it really matter if the protocol is exposed in URN or not? Have we e= ver > prefixed a file-path with anything? But is file name is locator or name o= r > identifier? > > On the other side, I do believe that we should have a URN. But my suggest= ion > is that we need only one set URN but not many. And the binding should be > kept in human knowledge as opposed to be defined in a protocol. > > I think we need a URN, which I called it schemeless URN. Take > http://example.com/earth as an example. The URN should be > > //example.com/earth > > I strongly object to your or anyone else's efforts to change > well-established standards and practice regarding URNs.=A0=A0 Those shoul= d be > entirely out of scope for this working group. > > I didn't want to change anything. I think the new URI spec is good to not > make a distinction between URN and URL. What I mean is if we need a URN, = we > should only define only one set of URN and to make it a name, do not bind= it > (i.e., a via specification) with any transportation protocol. That would > make it a pure (technically) name. > > Otherwise, as long as a specification is defined to bind a particularly > schemed URN to some transportation protocol, then it is no different from= a > URL. Or, if no binding whatsoever, the name is practically useless.=A0 It= is > as simple as that. > > Xiaoshu > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn > > From moore@network-heretics.com Wed Apr 28 19:38:17 2010 Return-Path: X-Original-To: urn@core3.amsl.com Delivered-To: urn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EDD93A6A5C for ; Wed, 28 Apr 2010 19:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.152 X-Spam-Level: X-Spam-Status: No, score=0.152 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_50=0.001, 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 VCX5GGeACOO6 for ; Wed, 28 Apr 2010 19:38:15 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 4E88B3A69A2 for ; Wed, 28 Apr 2010 19:38:15 -0700 (PDT) Received: from lust.indecency.org (174-151-122-31.pools.spcsdns.net [174.151.122.31]) by m1.imap-partners.net (MOS 4.1.8-GA) with ESMTP id BQZ57455 (AUTH admin@network-heretics.com); Wed, 28 Apr 2010 19:37:56 -0700 X-Mirapoint-Received-SPF: 174.151.122.31 lust.indecency.org 5 none X-Mirapoint-Received-SPF: 174.151.122.31 lust.indecency.org 5 none X-Mirapoint-Received-SPF: 174.151.122.31 lust.indecency.org 5 none Message-ID: <4BD8F103.8010003@network-heretics.com> Date: Wed, 28 Apr 2010 22:37:55 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: xiao@renci.org References: <201004280802.KAA11778@TR-Sys.de> <4BD83069.6060407@gmx.de> <4BD83B51.7010100@renci.org> <4BD83F7D.1050100@network-heretics.com> <4BD845CD.4060100@renci.org> <4BD847A2.8090204@network-heretics.com> <4BD84969.9000109@renci.org> <4BD86147.3030401@network-heretics.com> <4BD863CA.3050004@renci.org> <4BD8772D.7080601@network-heretics.com> <4BD87BEA.9070309@renci.org> <4BD888C7.5080801@network-heretics.com> <4BD89B92.8000501@renci.org> <4BD8BF32.7030201@network-heretics.com> <4BD8CB0F.5030602@renci.org> In-Reply-To: <4BD8CB0F.5030602@renci.org> Content-Type: multipart/alternative; boundary="------------010102070803010205050808" Cc: "urn@ietf.org" Subject: Re: [urn] fragment identifiers, Re: rfc2141bis [was: Re: A first cut at the Draft Charter ...] X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 02:38:17 -0000 This is a multi-part message in MIME format. --------------010102070803010205050808 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 4/28/10 7:55 PM, Xiaoshu Wang wrote: >>>> e.g. in many cases when you download a file using an http: URL, >>>> what you require is not that you get some "representation" of the >>>> resource named by that URL, but an exact copy of that resource. >>> It is an implicit assumption. But I do not believe that it is true >>> or it has to be true. >> For some uses of the HTTP protocol and http: URLs, it absolutely has >> to be true. > Really? Show me an example that if they do not take that assumption, > it will fail. downloading any encrypted or cryptographically signed resource. another example: executable code. >> The intended purpose of URNs is not to name fruits. It is to name >> network-accessible resources. > Most people that I work with, they want names for genes, proteins, > molecules, diseases, etc. Perhaps URNs were not intended to solve those people's naming problems? If they can be used for those purposes without violating the design of URNs, fine, but that's not a justification for changing the design. Especially when using URNs in a way that is contrary to their design dilutes the intended utility of URNs. > But again, these can be network-accessible resources as you have not > given me a definition that I can tell one from others. actually, I have. well, maybe you can't tell, but the distinction exists. >>>>> "http://example.com/earth" is a name referring to the Earth. >>>>> Dereferencing it gets you a representation of the Earth, but not >>>>> the Earth itself. >>>> If you coin a URI you get to decide what that URI is bound to. You >>>> get to decide whether it refers to a very specific sequence of >>>> octets, or to something a bit fuzzier. But saying that you're >>>> coining a URI for the Earth when the best you can ever hope to >>>> return is an extremely inexact representation of it, seems grossly >>>> imprecise at best, and probably not a good example on which to base >>>> a protocol engineering discussion. >>> Nope. Let me repeat that. A URI does not necessarily refer to a >>> sequence of octets stream. >> Correct so far (except for the "Nope"), and this is consistent with >> what I wrote above. >>> Of course, we can make them to. But that requires more information. >> It doesn't require more explicit information. Either the origin >> server acts predictably or it doesn't. > Predictably with regard of what? If "http://example.com/aThing" names > a thing, what do you expect it to be? It's whatever the origin server named by example.com (at port 80) returns when given a GET request for /aThing. > Thus, getting back your early question, how do you measure failure? > Please explicit your criteria. >>> Again, you use some ambiguous words -- "extremely inexact", please >>> define it. >> I'm using the words in their usual sense. > That is what you mean a technical definition? I'm not going to play this game with you. >>> Say, http://www.w3.org, do you believe that there is an exact copy >>> of what you see from your browser? Does it matter? The same with >>> your Word Doc example! Exact or in-exact, what is it compared to? >>> And by which criteria? >> Every single day, the vast majority of the files that I download need >> to be exact copies of what is on the origin server. > Is Resources == Files? What is that you downloaded? Resource or > Representation? A file is one kind of resource. Most of the resources I access via the web are files. Most of the time, I need exact copies of those files. > What is the widespread existing behavior that any of these will > change? First, I don't think there is anything that will be changed. > It just makes people to think/describe things more clearly. It's all well and good to clarify things. > Second, even if it requires changes, if it is for a better world, why > not? Because it won't work. You can't specify significant changes to the way URNs work without breaking them. That and who is to say that your idea of a better world is really better? >>> That is where the wrong lies. There isn't a problem in the past >>> because most information system, there is a one-to-one relationship >>> between the identifier and representation. Thus, we never bothered >>> or dared to use those identifier to reference anything-else. >> That was, in many cases, a feature. > A feature of ? simplicity. robustness. predictability. interoperability. >> IMO, there should not be a group to "revise" URNs. At most, the >> group should remove ambiguities and correct errata that are present >> in the existing specifications. > Then, what is the errata? I don't know. But if any are identified, we should of course try to correct them. >>>>>>>> And when we talk about using well-established protocols like >>>>>>>> http URIs or even URNs in an abstract fashion that doesn't >>>>>>>> consider the huge body of existing practice, it's hard to >>>>>>>> imagine that anything useful will come of it. >>>>>>> You bring another ambiguous concept -- "abstraction" -- into >>>>>>> discussion. Again, it will be your burden of proof to clarify >>>>>>> the distinction. >>>>>> I beg your pardon? I don't think I have to prove anything to >>>>>> you about URNs. >>>>> You uses a lot of concepts, such as "abstract", "ideas", etc. in >>>>> the dispute. But the truth is all these are philosophical >>>>> debatable concept. My thesis is very simple: as long as we >>>>> understand the asymmetry between reference and dereference, >>>>> everything is clear. >>>> Well, I think it's confusing to use "reference" to refer to the >>>> creation of a binding from a URI to a resource, and "dereference" >>>> to refer to the obtaining of a copy (or representation) of that >>>> resource given the URI. But of course these are two distinct >>>> operations. >>> What is the confusion? >>> URI -- references --> A Resource >>> URI -- dereferenced_to --> A Representation >>> And Resource != Representation >>> >>> Isn't that simple and clear enough? >> No, it's incorrect in lots of very subtle ways. > Tell me where it is wrong. The reverse would be: dereference = > reference or Resource = Representation. If this is your plea, you will > have a very huge gap to bridge -- The DeCartian Gap. Offhand, I don't know how to describe this in terms that you will understand. >>> As you said, URN should not be bound with any protocol or network. >>> Then, how we should ever discuss that. If we talked about it, then >>> there is a binding somewhere/somehow, right? Then, a URN isn't >>> "technically" a URN. It is still a URL. >> Of course the URN can be bound to access protocols, server addresses, >> etc. It's just that the binding isn't exposed in the URN itself. >> It's allowed to change over time. > Does it really matter if the protocol is exposed in URN or not? If you have to ask that question, then you clearly don't understand either the purpose or the design of URNs. >>> On the other side, I do believe that we should have a URN. But my >>> suggestion is that we need only one set URN but not many. And the >>> binding should be kept in human knowledge as opposed to be defined >>> in a protocol. >>> >>> I think we need a URN, which I called it schemeless URN. Take >>> http://example.com/earth as an example. The URN should be >>> >>> //example.com/earth >> I strongly object to your or anyone else's efforts to change >> well-established standards and practice regarding URNs. Those >> should be entirely out of scope for this working group. > I didn't want to change anything. I think the new URI spec is good to > not make a distinction between URN and URL. Perhaps the distinction doesn't belong in the URI spec, as it might properly be out of scope for that document. But the distinction still exists. > What I mean is if we need a URN, we should only define only one set of > URN and to make it a name, do not bind it (i.e., a via specification) > with any transportation protocol. That would make it a pure > (technically) name. Have you even read the URN specifications? Keith --------------010102070803010205050808 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 4/28/10 7:55 PM, Xiaoshu Wang wrote:
e.g. in many cases when you download a file using an http: URL, what you require is not that you get some "representation" of the resource named by that URL, but an exact copy of that resource.
It is an implicit assumption. But I do not believe that it is true or it has to be true.
For some uses of the HTTP protocol and http: URLs, it absolutely has to be true.
Really? Show me an example that if they do not take that assumption, it will fail.
downloading any encrypted or cryptographically signed resource.  another example: executable code. 
The intended purpose of URNs is not to name fruits.  It is to name network-accessible resources.
Most people that I work with, they want names for genes, proteins, molecules, diseases, etc.
Perhaps URNs were not intended to solve those people's naming problems?  If they can be used for those purposes without violating the design of URNs, fine, but that's not a justification for changing the design.  Especially when using URNs in a way that is contrary to their design dilutes the intended utility of URNs.
But again, these can be network-accessible resources as you have not given me a definition that I can tell one from others.
actually, I have.    well, maybe you can't tell, but the distinction exists.
"http://example.com/earth" is a name referring to the Earth. Dereferencing it gets you a representation of the Earth, but not the Earth itself.
If you coin a URI you get to decide what that URI is bound to.  You get to decide whether it refers to a very specific sequence of octets, or to something a bit fuzzier.  But saying that you're coining a URI for the Earth when the best you can ever hope to return is an extremely inexact representation of it, seems grossly imprecise at best, and probably not a good example on which to base a protocol engineering discussion.
Nope. Let me repeat that. A URI does not necessarily refer to a sequence of octets stream.
Correct so far (except for the "Nope"), and this is consistent with what I wrote above.
Of course, we can make them to. But that requires more information.
It doesn't require more explicit information.    Either the origin server acts predictably or it doesn't.  
Predictably with regard of what? If "http://example.com/aThing" names a thing, what do you expect it to be?
It's whatever the origin server named by example.com (at port 80) returns when given a GET request for /aThing.
Thus, getting back your early question, how do you measure failure? Please explicit your criteria.
Again, you use some ambiguous words -- "extremely inexact", please define it.
I'm using the words in their usual sense.
That is what you mean a technical definition?
I'm not going to play this game with you. 
Say, http://www.w3.org, do you believe that there is an exact copy of what you see from your browser? Does it matter? The same with your Word Doc example! Exact or in-exact, what is it compared to? And by which criteria?
Every single day, the vast majority of the files that I download need to be exact copies of what is on the origin server.
Is Resources == Files? What is that you downloaded? Resource or Representation?
A file is one kind of resource.  Most of the resources I access via the web are files.  Most of the time, I need exact copies of those files.
What is the widespread existing behavior that any of these will change? First, I don't think there is anything that will be changed. It just makes people to think/describe things more clearly.
It's all well and good to clarify things.
Second, even if it requires changes, if it is for a better world, why not?
Because it won't work.  You can't specify significant changes to the way URNs work without breaking them.  That and who is to say that your idea of a better world is really better?
That is where the wrong lies. There isn't a problem in the past because most information system, there is a one-to-one relationship between the identifier and representation. Thus, we never bothered or dared to use those identifier to reference anything-else.
That was, in many cases, a feature.
A feature of ?
simplicity.  robustness.  predictability.  interoperability. 
IMO, there should not be a group to "revise" URNs.   At most, the group should remove ambiguities and correct errata that are present in the existing specifications.
Then, what is the errata?
I don't know.  But if any are identified, we should of course try to correct them.

And when we talk about using well-established protocols like http URIs or even URNs in an abstract fashion that doesn't consider the huge body of existing practice, it's hard to imagine that anything useful will come of it.
You bring another ambiguous concept -- "abstraction" -- into discussion. Again, it will be your burden of proof to clarify the distinction.
I beg your pardon?   I don't think I have to prove anything to you about URNs.
You uses a lot of concepts, such as "abstract", "ideas", etc. in the dispute. But the truth is all these are philosophical debatable concept. My thesis is very simple: as long as we understand the asymmetry between reference and dereference, everything is clear.
Well, I think it's confusing to use "reference" to refer to the creation of a binding from a URI to a resource, and "dereference" to refer to the obtaining of a copy (or representation) of that resource given the URI.  But of course these are two distinct operations. 
What is the confusion?
URI -- references --> A Resource
URI -- dereferenced_to --> A Representation
And Resource != Representation

Isn't that simple and clear enough?
No, it's incorrect in lots of very subtle ways.
Tell me where it is wrong. The reverse would be: dereference = reference or Resource = Representation. If this is your plea, you will have a very huge gap to bridge -- The DeCartian Gap.
Offhand, I don't know how to describe this in terms that you will understand.
As you said, URN should not be bound with any protocol or network. Then, how we should ever discuss that. If we talked about it, then there is a binding somewhere/somehow, right? Then, a URN isn't "technically" a URN. It is still a URL.
Of course the URN can be bound to access protocols, server addresses, etc.   It's just that the binding isn't exposed in the URN itself.  It's allowed to change over time.
Does it really matter if the protocol is exposed in URN or not?
If you have to ask that question, then you clearly don't understand either the purpose or the design of URNs.
On the other side, I do believe that we should have a URN. But my suggestion is that we need only one set URN but not many. And the binding should be kept in human knowledge as opposed to be defined in a protocol.

I think we need a URN, which I called it schemeless URN. Take http://example.com/earth as an example. The URN should be

//example.com/earth
I strongly object to your or anyone else's efforts to change well-established standards and practice regarding URNs.   Those should be entirely out of scope for this working group. 
I didn't want to change anything. I think the new URI spec is good to not make a distinction between URN and URL.
Perhaps the distinction doesn't belong in the URI spec, as it might properly be out of scope for that document.  But the distinction still exists.
What I mean is if we need a URN, we should only define only one set of URN and to make it a name, do not bind it (i.e., a via specification) with any transportation protocol. That would make it a pure (technically) name.
Have you even read the URN specifications?

Keith


--------------010102070803010205050808-- From moore@network-heretics.com Wed Apr 28 19:42:02 2010 Return-Path: X-Original-To: urn@core3.amsl.com Delivered-To: urn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A4DA3A6A5C for ; Wed, 28 Apr 2010 19:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.234 X-Spam-Level: X-Spam-Status: No, score=-0.234 tagged_above=-999 required=5 tests=[AWL=0.505, BAYES_20=-0.74, 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 WHZk3cvZFQqh for ; Wed, 28 Apr 2010 19:42:00 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id C1C3F3A6A3E for ; Wed, 28 Apr 2010 19:42:00 -0700 (PDT) Received: from lust.indecency.org (174-151-122-31.pools.spcsdns.net [174.151.122.31]) by m1.imap-partners.net (MOS 4.1.8-GA) with ESMTP id BQZ57885 (AUTH admin@network-heretics.com); Wed, 28 Apr 2010 19:41:42 -0700 X-Mirapoint-Received-SPF: 174.151.122.31 lust.indecency.org 5 none X-Mirapoint-Received-SPF: 174.151.122.31 lust.indecency.org 5 none X-Mirapoint-Received-SPF: 174.151.122.31 lust.indecency.org 5 none X-Mirapoint-Received-SPF: 174.151.122.31 lust.indecency.org 5 none Message-ID: <4BD8F1E4.7080803@network-heretics.com> Date: Wed, 28 Apr 2010 22:41:40 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Ted Hardie References: <201004280802.KAA11778@TR-Sys.de> <4BD84969.9000109@renci.org> <4BD86147.3030401@network-heretics.com> <4BD863CA.3050004@renci.org> <4BD8772D.7080601@network-heretics.com> <4BD87BEA.9070309@renci.org> <4BD888C7.5080801@network-heretics.com> <4BD89B92.8000501@renci.org> <4BD8BF32.7030201@network-heretics.com> <4BD8CB0F.5030602@renci.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010405070704020002000000" Cc: "urn@ietf.org" Subject: Re: [urn] fragment identifiers, Re: rfc2141bis [was: Re: A first cut at the Draft Charter ...] X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 02:42:02 -0000 This is a multi-part message in MIME format. --------------010405070704020002000000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 4/28/10 8:52 PM, Ted Hardie wrote: > Howdy, > > This is top posted, rather than in-line because it is a meta point. > > The text of RFC 2141 includes this: > > Uniform Resource Names (URNs) are intended to serve as persistent, > location-independent, resource identifiers and are designed to make > it easy to map other namespaces (which share the properties of URNs) > into URN-space. > > The mechanism used to signal that something is a URN (and therefore is > intended to have these properties) is to use the URN scheme and a > namespace identifier, which in turn indicates how those properties are > achieved (commonly with an organization managing the namespace). > > If there are other properties desired, other URI schemes may be more > appropriate choices. There are 40 defined URN namsepaces in use now, > and the principle of least surprise says that we need to make sure any > changes this group might make to the documents does not violate the > expectations on > which they have built their systems. You might note, for example, that > the XMPP namespaces that use URNs include at least one with a fragment > identifier: > > http://xmpp.org/registrar/namespaces.html > > While we might include information for namespace authorities about how > best to use these, taking the tack now that they are not permitted is > inappropriate > because it would violate the persistence principle inherent in URNs. > > Generalizing that a bit, I suspect that a group working on URN-related documents > can update the language and BNF and can make sure the registration procedures > are clear, but it has to have limited scope. Any basic change to syntax > or semantics has the potential for impact on the namespaces already in use; > anything that does that has to be a non-starter because of the need to maintain > a consistency. seems entirely reasonable. Keith --------------010405070704020002000000 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 4/28/10 8:52 PM, Ted Hardie wrote: 
Howdy,

This is top posted, rather than in-line because it is a meta point.

The text of RFC 2141 includes this:

   Uniform Resource Names (URNs) are intended to serve as persistent,
   location-independent, resource identifiers and are designed to make
   it easy to map other namespaces (which share the properties of URNs)
   into URN-space.

The mechanism used to signal that something is a URN (and therefore is
intended to have these properties) is to use the URN scheme and a
namespace identifier, which in turn indicates how those properties are
achieved (commonly with an organization managing the namespace).

If there are other properties desired, other URI schemes may be more
appropriate choices.    There are 40 defined URN namsepaces in use now,
and the principle of least surprise says that we need to make sure any
changes this group might make to the documents does not violate the
expectations on
which they have built their systems.  You might note, for example, that
the XMPP namespaces that use URNs include at least one with a fragment
identifier:

http://xmpp.org/registrar/namespaces.html

While we might include information for  namespace authorities about how
best to use these, taking the tack now that they are not permitted is
inappropriate
because it would violate the persistence principle inherent in URNs.

Generalizing that a bit, I suspect that a group working on URN-related documents
can update the language and BNF and can make sure the registration procedures
are clear, but it has to have limited scope.  Any basic change to syntax
or semantics has the potential for impact on the namespaces already in use;
anything that does that has to be a non-starter because of the need to maintain
a consistency.
seems entirely reasonable.

Keith

--------------010405070704020002000000-- From xiao@renci.org Thu Apr 29 03:54:33 2010 Return-Path: X-Original-To: urn@core3.amsl.com Delivered-To: urn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92EE83A6C69 for ; Thu, 29 Apr 2010 03:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.091 X-Spam-Level: X-Spam-Status: No, score=-0.091 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEgOdAr8fPk5 for ; Thu, 29 Apr 2010 03:54:31 -0700 (PDT) Received: from mx1.renci.org (email.renci.org [152.54.4.63]) by core3.amsl.com (Postfix) with ESMTP id 160CC3A6C66 for ; Thu, 29 Apr 2010 03:54:23 -0700 (PDT) Received: from Xiaoshu-MacBook-Pro.local (cpe-065-190-193-065.nc.res.rr.com [65.190.193.65]) (authenticated bits=0) by mx1.renci.org (8.14.2/8.14.2) with ESMTP id o3TAs8qv004939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Apr 2010 06:54:08 -0400 Message-ID: <4BD96550.9090403@renci.org> Date: Thu, 29 Apr 2010 06:54:08 -0400 From: Xiaoshu Wang User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Keith Moore References: <201004280802.KAA11778@TR-Sys.de> <4BD83069.6060407@gmx.de> <4BD83B51.7010100@renci.org> <4BD83F7D.1050100@network-heretics.com> <4BD845CD.4060100@renci.org> <4BD847A2.8090204@network-heretics.com> <4BD84969.9000109@renci.org> <4BD86147.3030401@network-heretics.com> <4BD863CA.3050004@renci.org> <4BD8772D.7080601@network-heretics.com> <4BD87BEA.9070309@renci.org> <4BD888C7.5080801@network-heretics.com> <4BD89B92.8000501@renci.org> <4BD8BF32.7030201@network-heretics.com> <4BD8CB0F.5030602@renci.org> <4BD8F103.8010003@network-heretics.com> In-Reply-To: <4BD8F103.8010003@network-heretics.com> Content-Type: multipart/alternative; boundary="------------020801010908070304020207" X-MS-Exchange-Organization-SCL: 2 X-Scanned-By: MIMEDefang 2.63 on 152.54.4.60 Cc: "urn@ietf.org" Subject: Re: [urn] fragment identifiers, Re: rfc2141bis [was: Re: A first cut at the Draft Charter ...] X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: xiao@renci.org List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 10:54:33 -0000 This is a multi-part message in MIME format. --------------020801010908070304020207 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 4/28/10 10:37 PM, Keith Moore wrote: > On 4/28/10 7:55 PM, Xiaoshu Wang wrote: >>>>> e.g. in many cases when you download a file using an http: URL, >>>>> what you require is not that you get some "representation" of the >>>>> resource named by that URL, but an exact copy of that resource. >>>> It is an implicit assumption. But I do not believe that it is true >>>> or it has to be true. >>> For some uses of the HTTP protocol and http: URLs, it absolutely has >>> to be true. >> Really? Show me an example that if they do not take that assumption, >> it will fail. > downloading any encrypted or cryptographically signed resource. > another example: executable code. Change the word "resource" to representation, anything breaks? >>> The intended purpose of URNs is not to name fruits. It is to name >>> network-accessible resources. >> Most people that I work with, they want names for genes, proteins, >> molecules, diseases, etc. > Perhaps URNs were not intended to solve those people's naming > problems? If they can be used for those purposes without violating > the design of URNs, fine, but that's not a justification for changing > the design. Especially when using URNs in a way that is contrary to > their design dilutes the intended utility of URNs. Changing what design? >> But again, these can be network-accessible resources as you have not >> given me a definition that I can tell one from others. > actually, I have. well, maybe you can't tell, but the distinction > exists. This is the problem. Everyone has its own distinction but no standard one. >>>>>> "http://example.com/earth" is a name referring to the Earth. >>>>>> Dereferencing it gets you a representation of the Earth, but not >>>>>> the Earth itself. >>>>> If you coin a URI you get to decide what that URI is bound to. >>>>> You get to decide whether it refers to a very specific sequence of >>>>> octets, or to something a bit fuzzier. But saying that you're >>>>> coining a URI for the Earth when the best you can ever hope to >>>>> return is an extremely inexact representation of it, seems grossly >>>>> imprecise at best, and probably not a good example on which to >>>>> base a protocol engineering discussion. >>>> Nope. Let me repeat that. A URI does not necessarily refer to a >>>> sequence of octets stream. >>> Correct so far (except for the "Nope"), and this is consistent with >>> what I wrote above. >>>> Of course, we can make them to. But that requires more information. >>> It doesn't require more explicit information. Either the origin >>> server acts predictably or it doesn't. >> Predictably with regard of what? If "http://example.com/aThing" names >> a thing, what do you expect it to be? > It's whatever the origin server named by example.com (at port 80) > returns when given a GET request for /aThing. Then, what is not predictable? >> Thus, getting back your early question, how do you measure failure? >> Please explicit your criteria. >>>> Again, you use some ambiguous words -- "extremely inexact", please >>>> define it. >>> I'm using the words in their usual sense. >> That is what you mean a technical definition? > I'm not going to play this game with you. >>>> Say, http://www.w3.org, do you believe that there is an exact copy >>>> of what you see from your browser? Does it matter? The same with >>>> your Word Doc example! Exact or in-exact, what is it compared to? >>>> And by which criteria? >>> Every single day, the vast majority of the files that I download >>> need to be exact copies of what is on the origin server. >> Is Resources == Files? What is that you downloaded? Resource or >> Representation? > A file is one kind of resource. Most of the resources I access via > the web are files. Most of the time, I need exact copies of those files. Most of the resources you accesses are web servers, which backend is a process. What you received is a file. >> What is the widespread existing behavior that any of these will >> change? First, I don't think there is anything that will be changed. >> It just makes people to think/describe things more clearly. > It's all well and good to clarify things. >> Second, even if it requires changes, if it is for a better world, why >> not? > Because it won't work. You can't specify significant changes to the > way URNs work without breaking them. That and who is to say that your > idea of a better world is really better? >>>> That is where the wrong lies. There isn't a problem in the past >>>> because most information system, there is a one-to-one relationship >>>> between the identifier and representation. Thus, we never bothered >>>> or dared to use those identifier to reference anything-else. >>> That was, in many cases, a feature. >> A feature of ? > simplicity. robustness. predictability. interoperability. Sigh....you just make claim, never use an example to justify it. I or anyonelse can do the same. That doesn't help persuade people's opinion. >>> IMO, there should not be a group to "revise" URNs. At most, the >>> group should remove ambiguities and correct errata that are present >>> in the existing specifications. >> Then, what is the errata? > I don't know. But if any are identified, we should of course try to > correct them. > >>>>>>>>> And when we talk about using well-established protocols like >>>>>>>>> http URIs or even URNs in an abstract fashion that doesn't >>>>>>>>> consider the huge body of existing practice, it's hard to >>>>>>>>> imagine that anything useful will come of it. >>>>>>>> You bring another ambiguous concept -- "abstraction" -- into >>>>>>>> discussion. Again, it will be your burden of proof to clarify >>>>>>>> the distinction. >>>>>>> I beg your pardon? I don't think I have to prove anything to >>>>>>> you about URNs. >>>>>> You uses a lot of concepts, such as "abstract", "ideas", etc. in >>>>>> the dispute. But the truth is all these are philosophical >>>>>> debatable concept. My thesis is very simple: as long as we >>>>>> understand the asymmetry between reference and dereference, >>>>>> everything is clear. >>>>> Well, I think it's confusing to use "reference" to refer to the >>>>> creation of a binding from a URI to a resource, and "dereference" >>>>> to refer to the obtaining of a copy (or representation) of that >>>>> resource given the URI. But of course these are two distinct >>>>> operations. >>>> What is the confusion? >>>> URI -- references --> A Resource >>>> URI -- dereferenced_to --> A Representation >>>> And Resource != Representation >>>> >>>> Isn't that simple and clear enough? >>> No, it's incorrect in lots of very subtle ways. >> Tell me where it is wrong. The reverse would be: dereference = >> reference or Resource = Representation. If this is your plea, you >> will have a very huge gap to bridge -- The DeCartian Gap. > Offhand, I don't know how to describe this in terms that you will > understand. >>>> As you said, URN should not be bound with any protocol or network. >>>> Then, how we should ever discuss that. If we talked about it, then >>>> there is a binding somewhere/somehow, right? Then, a URN isn't >>>> "technically" a URN. It is still a URL. >>> Of course the URN can be bound to access protocols, server >>> addresses, etc. It's just that the binding isn't exposed in the >>> URN itself. It's allowed to change over time. >> Does it really matter if the protocol is exposed in URN or not? > If you have to ask that question, then you clearly don't understand > either the purpose or the design of URNs. >>>> On the other side, I do believe that we should have a URN. But my >>>> suggestion is that we need only one set URN but not many. And the >>>> binding should be kept in human knowledge as opposed to be defined >>>> in a protocol. >>>> >>>> I think we need a URN, which I called it schemeless URN. Take >>>> http://example.com/earth as an example. The URN should be >>>> >>>> //example.com/earth >>> I strongly object to your or anyone else's efforts to change >>> well-established standards and practice regarding URNs. Those >>> should be entirely out of scope for this working group. >> I didn't want to change anything. I think the new URI spec is good to >> not make a distinction between URN and URL. > Perhaps the distinction doesn't belong in the URI spec, as it might > properly be out of scope for that document. But the distinction still > exists. Do you think that is the way that an IETF recommendation should be written? To define a protocol for something that they cannot define? >> What I mean is if we need a URN, we should only define only one set >> of URN and to make it a name, do not bind it (i.e., a via >> specification) with any transportation protocol. That would make it a >> pure (technically) name. > Have you even read the URN specifications? Of course, I do. Xiaoshu --------------020801010908070304020207 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 4/28/10 10:37 PM, Keith Moore wrote:
On 4/28/10 7:55 PM, Xiaoshu Wang wrote:
e.g. in many cases when you download a file using an http: URL, what you require is not that you get some "representation" of the resource named by that URL, but an exact copy of that resource.
It is an implicit assumption. But I do not believe that it is true or it has to be true.
For some uses of the HTTP protocol and http: URLs, it absolutely has to be true.
Really? Show me an example that if they do not take that assumption, it will fail.
downloading any encrypted or cryptographically signed resource.  another example: executable code. 
Change the word "resource" to representation, anything breaks?
The intended purpose of URNs is not to name fruits.  It is to name network-accessible resources.
Most people that I work with, they want names for genes, proteins, molecules, diseases, etc.
Perhaps URNs were not intended to solve those people's naming problems?  If they can be used for those purposes without violating the design of URNs, fine, but that's not a justification for changing the design.  Especially when using URNs in a way that is contrary to their design dilutes the intended utility of URNs.
Changing what design?
But again, these can be network-accessible resources as you have not given me a definition that I can tell one from others.
actually, I have.    well, maybe you can't tell, but the distinction exists.
This is the problem. Everyone has its own distinction but no standard one.
"http://example.com/earth" is a name referring to the Earth. Dereferencing it gets you a representation of the Earth, but not the Earth itself.
If you coin a URI you get to decide what that URI is bound to.  You get to decide whether it refers to a very specific sequence of octets, or to something a bit fuzzier.  But saying that you're coining a URI for the Earth when the best you can ever hope to return is an extremely inexact representation of it, seems grossly imprecise at best, and probably not a good example on which to base a protocol engineering discussion.
Nope. Let me repeat that. A URI does not necessarily refer to a sequence of octets stream.
Correct so far (except for the "Nope"), and this is consistent with what I wrote above.
Of course, we can make them to. But that requires more information.
It doesn't require more explicit information.    Either the origin server acts predictably or it doesn't.  
Predictably with regard of what? If "http://example.com/aThing" names a thing, what do you expect it to be?
It's whatever the origin server named by example.com (at port 80) returns when given a GET request for /aThing.
Then, what is not predictable?
Thus, getting back your early question, how do you measure failure? Please explicit your criteria.
Again, you use some ambiguous words -- "extremely inexact", please define it.
I'm using the words in their usual sense.
That is what you mean a technical definition?
I'm not going to play this game with you. 
Say, http://www.w3.org, do you believe that there is an exact copy of what you see from your browser? Does it matter? The same with your Word Doc example! Exact or in-exact, what is it compared to? And by which criteria?
Every single day, the vast majority of the files that I download need to be exact copies of what is on the origin server.
Is Resources == Files? What is that you downloaded? Resource or Representation?
A file is one kind of resource.  Most of the resources I access via the web are files.  Most of the time, I need exact copies of those files.
Most of the resources you accesses are web servers, which backend is a process. What you received is a file.
What is the widespread existing behavior that any of these will change? First, I don't think there is anything that will be changed. It just makes people to think/describe things more clearly.
It's all well and good to clarify things.
Second, even if it requires changes, if it is for a better world, why not?
Because it won't work.  You can't specify significant changes to the way URNs work without breaking them.  That and who is to say that your idea of a better world is really better?

That is where the wrong lies. There isn't a problem in the past because most information system, there is a one-to-one relationship between the identifier and representation. Thus, we never bothered or dared to use those identifier to reference anything-else.
That was, in many cases, a feature.
A feature of ?
simplicity.  robustness.  predictability.  interoperability. 
Sigh....you just make claim, never use an example to justify it. I or anyonelse can do the same. That doesn't help persuade people's opinion.
IMO, there should not be a group to "revise" URNs.   At most, the group should remove ambiguities and correct errata that are present in the existing specifications.
Then, what is the errata?
I don't know.  But if any are identified, we should of course try to correct them.

And when we talk about using well-established protocols like http URIs or even URNs in an abstract fashion that doesn't consider the huge body of existing practice, it's hard to imagine that anything useful will come of it.
You bring another ambiguous concept -- "abstraction" -- into discussion. Again, it will be your burden of proof to clarify the distinction.
I beg your pardon?   I don't think I have to prove anything to you about URNs.
You uses a lot of concepts, such as "abstract", "ideas", etc. in the dispute. But the truth is all these are philosophical debatable concept. My thesis is very simple: as long as we understand the asymmetry between reference and dereference, everything is clear.
Well, I think it's confusing to use "reference" to refer to the creation of a binding from a URI to a resource, and "dereference" to refer to the obtaining of a copy (or representation) of that resource given the URI.  But of course these are two distinct operations. 
What is the confusion?
URI -- references --> A Resource
URI -- dereferenced_to --> A Representation
And Resource != Representation

Isn't that simple and clear enough?
No, it's incorrect in lots of very subtle ways.
Tell me where it is wrong. The reverse would be: dereference = reference or Resource = Representation. If this is your plea, you will have a very huge gap to bridge -- The DeCartian Gap.
Offhand, I don't know how to describe this in terms that you will understand.
As you said, URN should not be bound with any protocol or network. Then, how we should ever discuss that. If we talked about it, then there is a binding somewhere/somehow, right? Then, a URN isn't "technically" a URN. It is still a URL.
Of course the URN can be bound to access protocols, server addresses, etc.   It's just that the binding isn't exposed in the URN itself.  It's allowed to change over time.
Does it really matter if the protocol is exposed in URN or not?
If you have to ask that question, then you clearly don't understand either the purpose or the design of URNs.
On the other side, I do believe that we should have a URN. But my suggestion is that we need only one set URN but not many. And the binding should be kept in human knowledge as opposed to be defined in a protocol.

I think we need a URN, which I called it schemeless URN. Take http://example.com/earth as an example. The URN should be

//example.com/earth
I strongly object to your or anyone else's efforts to change well-established standards and practice regarding URNs.   Those should be entirely out of scope for this working group. 
I didn't want to change anything. I think the new URI spec is good to not make a distinction between URN and URL.
Perhaps the distinction doesn't belong in the URI spec, as it might properly be out of scope for that document.  But the distinction still exists.
Do you think that is the way that an IETF recommendation should be written? To define a protocol for something that they cannot define?
What I mean is if we need a URN, we should only define only one set of URN and to make it a name, do not bind it (i.e., a via specification) with any transportation protocol. That would make it a pure (technically) name.
Have you even read the URN specifications?
Of course, I do.

Xiaoshu

--------------020801010908070304020207-- From julian.reschke@gmx.de Thu Apr 29 04:48:09 2010 Return-Path: X-Original-To: urn@core3.amsl.com Delivered-To: urn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 739083A6C7B for ; Thu, 29 Apr 2010 04:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.032 X-Spam-Level: X-Spam-Status: No, score=-3.032 tagged_above=-999 required=5 tests=[AWL=-3.033, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oL9Fzgr4L7Cw for ; Thu, 29 Apr 2010 04:48:08 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id D047F3A6C4C for ; Thu, 29 Apr 2010 04:47:43 -0700 (PDT) Received: (qmail invoked by alias); 29 Apr 2010 11:47:28 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.105]) [217.91.35.233] by mail.gmx.net (mp015) with SMTP; 29 Apr 2010 13:47:28 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/miTAy71/miUKaCfk9QrVqG3u07XrYPGMZQ/6DPC nWVan+r61xPel3 Message-ID: <4BD971C8.6000404@gmx.de> Date: Thu, 29 Apr 2010 13:47:20 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Ted Hardie References: <201004280802.KAA11778@TR-Sys.de> <4BD84969.9000109@renci.org> <4BD86147.3030401@network-heretics.com> <4BD863CA.3050004@renci.org> <4BD8772D.7080601@network-heretics.com> <4BD87BEA.9070309@renci.org> <4BD888C7.5080801@network-heretics.com> <4BD89B92.8000501@renci.org> <4BD8BF32.7030201@network-heretics.com> <4BD8CB0F.5030602@renci.org> 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.62 Cc: "urn@ietf.org" , Keith Moore Subject: Re: [urn] fragment identifiers, Re: rfc2141bis [was: Re: A first cut at the Draft Charter ...] X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 11:48:09 -0000 On 29.04.2010 02:52, Ted Hardie wrote: > Howdy, > > This is top posted, rather than in-line because it is a meta point. > > The text of RFC 2141 includes this: > > Uniform Resource Names (URNs) are intended to serve as persistent, > location-independent, resource identifiers and are designed to make > it easy to map other namespaces (which share the properties of URNs) > into URN-space. > > The mechanism used to signal that something is a URN (and therefore is > intended to have these properties) is to use the URN scheme and a > namespace identifier, which in turn indicates how those properties are > achieved (commonly with an organization managing the namespace). > > If there are other properties desired, other URI schemes may be more > appropriate choices. There are 40 defined URN namsepaces in use now, > and the principle of least surprise says that we need to make sure any > changes this group might make to the documents does not violate the > expectations on > which they have built their systems. You might note, for example, that > the XMPP namespaces that use URNs include at least one with a fragment > identifier: > > http://xmpp.org/registrar/namespaces.html > > While we might include information for namespace authorities about how > best to use these, taking the tack now that they are not permitted is > inappropriate > because it would violate the persistence principle inherent in URNs. > ... To me, the important thing to clarify is that URNs are compatible with the generic URI format, thus, the first "#" character *always* starts a fragment identifier, and, consequently, if you need a "#" in the NSS (nanespace specific string), it needs to be percent-escaped. I *believe* everybody agrees on that, but checking doesn't hurt. That being said, what a fragid in a URN *means* is an orthogonal question. We can both point out that for now it may be a bad idea to rely on it, without actually breaking the cases where they are already used. > ... Best regards, Julian From duerst@it.aoyama.ac.jp Thu Apr 29 04:56:57 2010 Return-Path: X-Original-To: urn@core3.amsl.com Delivered-To: urn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BE723A6C7C for ; Thu, 29 Apr 2010 04:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.948 X-Spam-Level: ** X-Spam-Status: No, score=2.948 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kftQtSy3rnCN for ; Thu, 29 Apr 2010 04:56:55 -0700 (PDT) Received: from scmailgw02.scop.aoyama.ac.jp (scmailgw02.scop.aoyama.ac.jp [133.2.251.42]) by core3.amsl.com (Postfix) with ESMTP id 1D2603A6C90 for ; Thu, 29 Apr 2010 04:56:50 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp (scmse02.scbb.aoyama.ac.jp [133.2.253.159]) by scmailgw02.scop.aoyama.ac.jp (secret/secret) with SMTP id o3TBuS6I018207 for ; Thu, 29 Apr 2010 20:56:28 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 774a_3719_3eb96dd0_5386_11df_bc46_001d096c5782; Thu, 29 Apr 2010 20:56:28 +0900 Received: from [IPv6:::1] ([133.2.210.1]:35042) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 29 Apr 2010 20:56:29 +0900 Message-ID: <4BD973E9.8020903@it.aoyama.ac.jp> Date: Thu, 29 Apr 2010 20:56:25 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.4pre) Gecko/20091214 Eudora/3.0b4 MIME-Version: 1.0 To: Ted Hardie References: <201004280802.KAA11778@TR-Sys.de> <4BD84969.9000109@renci.org> <4BD86147.3030401@network-heretics.com> <4BD863CA.3050004@renci.org> <4BD8772D.7080601@network-heretics.com> <4BD87BEA.9070309@renci.org> <4BD888C7.5080801@network-heretics.com> <4BD89B92.8000501@renci.org> <4BD8BF32.7030201@network-heretics.com> <4BD8CB0F.5030602@renci.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "urn@ietf.org" , Keith Moore Subject: Re: [urn] fragment identifiers, Re: rfc2141bis [was: Re: A first cut at the Draft Charter ...] X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 11:56:57 -0000 Hello Ted, On 2010/04/29 9:52, Ted Hardie wrote: > If there are other properties desired, other URI schemes may be more > appropriate choices. There are 40 defined URN namsepaces in use now, > and the principle of least surprise says that we need to make sure any > changes this group might make to the documents does not violate the > expectations on > which they have built their systems. You might note, for example, that > the XMPP namespaces that use URNs include at least one with a fragment > identifier: > > http://xmpp.org/registrar/namespaces.html That would be urn:xmpp:langtrans#items. > While we might include information for namespace authorities about how > best to use these, taking the tack now that they are not permitted is > inappropriate > because it would violate the persistence principle inherent in URNs. Given what RFC 3986 says, it would definitely be difficult to prohibit using fragment identifiers on URI starting with "uri:" (i.e. URNs). But what Keith was wondering was whether the various properties that the URN spec says hold for URNs also hold if there is a fragment identifier attached to one of them. Although in the above single case, that probably wouldn't be a problem, I think it's difficult to guarantee this in general. I think people who want some extension to URN syntax but want to make sure it can be handled by resolution infrastructure in the most 'persistent' way should use something else than fragment identifiers. The reason is not only that fragment identifiers depend on the type of the returned resource, but also, or even much more, that fragment identifiers get resolved locally, not sent over the network. So e.g. if you want to create some persistent identifier for e.g some part of a book, but you want to make that book available in various representations, in some of which the identified part is a single entity, whereas in others it's a part of a file or it's several files, then you should either try with e.g. with a specific syntax extension or with a query syntax, not with a fragment identifier. Regards, Martin. -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From ted.ietf@gmail.com Thu Apr 29 07:29:20 2010 Return-Path: X-Original-To: urn@core3.amsl.com Delivered-To: urn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAF7C28C0EF for ; Thu, 29 Apr 2010 07:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.114 X-Spam-Level: X-Spam-Status: No, score=-0.114 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kIFTrfmODDSp for ; Thu, 29 Apr 2010 07:29:19 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 0688028C302 for ; Thu, 29 Apr 2010 07:26:14 -0700 (PDT) Received: by vws13 with SMTP id 13so1257060vws.31 for ; Thu, 29 Apr 2010 07:25:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Ttu283NX0sAP4s3hkElOTFlR2yQRwcdkO7Zl/7l73IE=; b=iGp08qWRsLd7LUHs3P+KfZOmZPTeKwDcCPPsIBQUCH84OxaFDcBBMbz9dH+nTFlLAF ffWeKPX/VSmSnOFJM9ibsYWbZS3ygg+0fy3dgFXo7RM7QsqznM6F4+A00C9ceEc9m19U QuTjzQeJzUanX/u6dimh0d+2TVhS25yRZKGbY= 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=pWD4ACLgCgMyyKDg8bibPiFwemZZ6iZyrZ/4V2itRh+0nEX0rb7EMzDuhcvBUiX6AS LW/8JvvYkQkPBN8jFi+1iA8fBOyPQzoVf7gCfXjXYLOefL67FKpPjmTk3grSDOJ3Fjfk ade7CSO+cO/hbMgOUUhJA4O8Vst8y4fGY6wQY= MIME-Version: 1.0 Received: by 10.220.121.152 with SMTP id h24mr2958419vcr.201.1272551157705; Thu, 29 Apr 2010 07:25:57 -0700 (PDT) Received: by 10.220.77.211 with HTTP; Thu, 29 Apr 2010 07:25:55 -0700 (PDT) In-Reply-To: <4BD971C8.6000404@gmx.de> References: <201004280802.KAA11778@TR-Sys.de> <4BD863CA.3050004@renci.org> <4BD8772D.7080601@network-heretics.com> <4BD87BEA.9070309@renci.org> <4BD888C7.5080801@network-heretics.com> <4BD89B92.8000501@renci.org> <4BD8BF32.7030201@network-heretics.com> <4BD8CB0F.5030602@renci.org> <4BD971C8.6000404@gmx.de> Date: Thu, 29 Apr 2010 07:25:55 -0700 Message-ID: From: Ted Hardie To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "urn@ietf.org" , Keith Moore Subject: Re: [urn] fragment identifiers, Re: rfc2141bis [was: Re: A first cut at the Draft Charter ...] X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 14:29:20 -0000 On Thu, Apr 29, 2010 at 4:47 AM, Julian Reschke wro= te: > On 29.04.2010 02:52, Ted Hardie wrote: >> >> Howdy, >> >> This is top posted, rather than in-line because it is a meta point. >> >> The text of RFC 2141 includes this: >> >> =A0 =A0Uniform Resource Names (URNs) are intended to serve as persistent= , >> =A0 =A0location-independent, resource identifiers and are designed to ma= ke >> =A0 =A0it easy to map other namespaces (which share the properties of UR= Ns) >> =A0 =A0into URN-space. >> >> The mechanism used to signal that something is a URN (and therefore is >> intended to have these properties) is to use the URN scheme and a >> namespace identifier, which in turn indicates how those properties are >> achieved (commonly with an organization managing the namespace). >> >> If there are other properties desired, other URI schemes may be more >> appropriate choices. =A0 =A0There are 40 defined URN namsepaces in use n= ow, >> and the principle of least surprise says that we need to make sure any >> changes this group might make to the documents does not violate the >> expectations on >> which they have built their systems. =A0You might note, for example, tha= t >> the XMPP namespaces that use URNs include at least one with a fragment >> identifier: >> >> http://xmpp.org/registrar/namespaces.html >> >> While we might include information for =A0namespace authorities about ho= w >> best to use these, taking the tack now that they are not permitted is >> inappropriate >> because it would violate the persistence principle inherent in URNs. >> ... > > To me, the important thing to clarify is that URNs are compatible with th= e > generic URI format, thus, the first "#" character *always* starts a fragm= ent > identifier, and, consequently, if you need a "#" in the NSS (nanespace > specific string), it needs to be percent-escaped. > > I *believe* everybody agrees on that, but checking doesn't hurt. I agree with this. > > That being said, what a fragid in a URN *means* is an orthogonal question= . > We can both point out that for now it may be a bad idea to rely on it, > without actually breaking the cases where they are already used. > >> ... Well, I think the presence of an unescaped # in a URN has whatever semantic meaning the namespace authority says it does. As long is it doesn't break the URN properties (persistence, chiefly) and matches the URI syntax, the semantics can vary from namespace to namespace. Just my opinion, of course, regards, Ted > > Best regards, Julian > From julian.reschke@gmx.de Thu Apr 29 07:35:11 2010 Return-Path: X-Original-To: urn@core3.amsl.com Delivered-To: urn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C1533A69B3 for ; Thu, 29 Apr 2010 07:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.254 X-Spam-Level: X-Spam-Status: No, score=-4.254 tagged_above=-999 required=5 tests=[AWL=-1.655, 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 azOgpzm5TvS1 for ; Thu, 29 Apr 2010 07:35:10 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id D7E693A6A73 for ; Thu, 29 Apr 2010 07:34:41 -0700 (PDT) Received: (qmail invoked by alias); 29 Apr 2010 14:34:27 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.105]) [217.91.35.233] by mail.gmx.net (mp012) with SMTP; 29 Apr 2010 16:34:27 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/Wkidzrr/WQlPGhn92ltRgVZc/7ZlFGSm4p7wPKE I+wxacK3Hke+da Message-ID: <4BD998EA.3020206@gmx.de> Date: Thu, 29 Apr 2010 16:34:18 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Ted Hardie References: <201004280802.KAA11778@TR-Sys.de> <4BD863CA.3050004@renci.org> <4BD8772D.7080601@network-heretics.com> <4BD87BEA.9070309@renci.org> <4BD888C7.5080801@network-heretics.com> <4BD89B92.8000501@renci.org> <4BD8BF32.7030201@network-heretics.com> <4BD8CB0F.5030602@renci.org> <4BD971C8.6000404@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.55000000000000004 Cc: "urn@ietf.org" , Keith Moore Subject: Re: [urn] fragment identifiers, Re: rfc2141bis [was: Re: A first cut at the Draft Charter ...] X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 14:35:11 -0000 On 29.04.2010 16:25, Ted Hardie wrote: > ... > Well, I think the presence of an unescaped # in a URN has whatever > semantic meaning the namespace authority says it does. As long is > it doesn't break the URN properties (persistence, chiefly) and > matches the URI syntax, the semantics can vary from namespace to > namespace. > ... So, looking at RFC 2141, Section 2.3.2 (): > 2.3.2 The other reserved characters > > > RFC 1630 [2] reserves the characters "/", "?", and "#" for particular > purposes. The URN-WG has not yet debated the applicability and > precise semantics of those purposes as applied to URNs. Therefore, > these characters are RESERVED for future developments. Namespace > developers SHOULD NOT use these characters in unencoded form, but > rather use the appropriate %-encoding for each character. I think this needs to change (for "#") to say "MUST NOT". Otherwise the spec would give the impression that there are legitimate cases where a "#" can appear in the NSS. Best regards, Julian From ted.ietf@gmail.com Thu Apr 29 07:40:35 2010 Return-Path: X-Original-To: urn@core3.amsl.com Delivered-To: urn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2F753A6A88 for ; Thu, 29 Apr 2010 07:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.044 X-Spam-Level: X-Spam-Status: No, score=0.044 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_50=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0gvNi7R3x92 for ; Thu, 29 Apr 2010 07:40:34 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 5C1B53A69B9 for ; Thu, 29 Apr 2010 07:40:33 -0700 (PDT) Received: by vws13 with SMTP id 13so1272744vws.31 for ; Thu, 29 Apr 2010 07:40:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JfZTulr+oW+c17sGbQW53P2oH+cBH7BmERPUw8enkYU=; b=tUTPW7/qsoC8rBZmNGyt8Vpgkdf7OxrnYQHcJigfnurlpemH9m4t+pncUD3wh4d+BU heGMweoDWBELveubYAVQPzpYcsTlxkQhT+jd4t2zwgHa2nSzuBPmnmaLMQTaqr+kzzB+ nLFMMBvMz2teejns/Mi88iPBH7dB4We1DE0XQ= 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=IUgAYC7ypasaBB8T3QmUrdfbw4bMOWFDF5SIwQ60GmH7zGieWWkCVx57naEEg2+nYn P2HmO/dQiJmoY/tZKYGixLdtOEGQoT+pFo5biTXakhfBxX+OZxemypTEQoEDXgP/NM0H fG28MknVG6WQW2R3f3R9tB8zouiKQGGa2NLgI= MIME-Version: 1.0 Received: by 10.220.157.136 with SMTP id b8mr6669168vcx.150.1272552019157; Thu, 29 Apr 2010 07:40:19 -0700 (PDT) Received: by 10.220.77.211 with HTTP; Thu, 29 Apr 2010 07:40:18 -0700 (PDT) In-Reply-To: <4BD973E9.8020903@it.aoyama.ac.jp> References: <201004280802.KAA11778@TR-Sys.de> <4BD863CA.3050004@renci.org> <4BD8772D.7080601@network-heretics.com> <4BD87BEA.9070309@renci.org> <4BD888C7.5080801@network-heretics.com> <4BD89B92.8000501@renci.org> <4BD8BF32.7030201@network-heretics.com> <4BD8CB0F.5030602@renci.org> <4BD973E9.8020903@it.aoyama.ac.jp> Date: Thu, 29 Apr 2010 07:40:18 -0700 Message-ID: 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: "urn@ietf.org" , Keith Moore Subject: Re: [urn] fragment identifiers, Re: rfc2141bis [was: Re: A first cut at the Draft Charter ...] X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 14:40:35 -0000 On Thu, Apr 29, 2010 at 4:56 AM, "Martin J. D=FCrst" wrote: > Hello Ted, > =A0You might note, for example, that >> the XMPP namespaces that use URNs include at least one with a fragment >> identifier: >> >> http://xmpp.org/registrar/namespaces.html > > That would be urn:xmpp:langtrans#items. > Yes. >> While we might include information for =A0namespace authorities about ho= w >> best to use these, taking the tack now that they are not permitted is >> inappropriate >> because it would violate the persistence principle inherent in URNs. > > Given what RFC 3986 says, it would definitely be difficult to prohibit us= ing > fragment identifiers on URI starting with "uri:" (i.e. URNs). But what Ke= ith > was wondering was whether the various properties that the URN spec says h= old > for URNs also hold if there is a fragment identifier attached to one of > them. Although in the above single case, that probably wouldn't be a > problem, I think it's difficult to guarantee this in general. > Well, as I said in my reply to Julian, I think the semantics of fragment identifiers is up to the individual namespace authorities. But I think the properties = are not. If you are a namespace authority, you are signing up to mint URNs that have the properties described in RFC 2141. You have a syntax in which to do that, and that includes fragment identifiers. But if you wish to min= t and identifier which does not have those properties (because it is unique t= o a specific format, for example), then you should mint it with some other identifier scheme. We have several available already (tag, to take the most obvious) and we could create more if needed. > I think people who want some extension to URN syntax but want to make sur= e > it can be handled by resolution infrastructure in the most 'persistent' w= ay > should use something else than fragment identifiers. The reason is not on= ly > that fragment identifiers depend on the type of the returned resource, bu= t > also, or even much more, that fragment identifiers get resolved locally, = not > sent over the network. So e.g. if you want to create some persistent > identifier for e.g some part of a book, but you want to make that book > available in various representations, in some of which the identified par= t > is a single entity, whereas in others it's a part of a file or it's sever= al > files, then you should either try with e.g. with a specific syntax extens= ion > or with a query syntax, not with a fragment identifier. > If I am understanding you correctly, a persistent identifier in the "parts of the book" example like #chapter7 makes sense to me, because that identifier relates t= o an internal structural component that is itself persistent. An example lik= e #pp77-90 does not, because the number of pages may vary in different representations. If there is no internal structural element that can be us= ed to identify pages 77-90, I would personally say that some real thought should be put into the question of whether or not a URN is the right type of identifier for this. Using one of the other available types might be better, even if a URN is the right type for the book itself or even the boo= k and its chapters. I have not thought in a long while about what query syntax might mean here, though, and I'll have think about that some more. regards, Ted > Regards, =A0 Martin. > > -- > #-# Martin J. D=FCrst, Professor, Aoyama Gakuin University > #-# http://www.sw.it.aoyama.ac.jp =A0 mailto:duerst@it.aoyama.ac.jp > From A.Hoenes@TR-Sys.de Thu Apr 29 08:19:21 2010 Return-Path: X-Original-To: urn@core3.amsl.com Delivered-To: urn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72DEB28C133 for ; Thu, 29 Apr 2010 08:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.768 X-Spam-Level: X-Spam-Status: No, score=-95.768 tagged_above=-999 required=5 tests=[AWL=-0.219, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3I5nSjZf7iI for ; Thu, 29 Apr 2010 08:19:20 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id D20F73A6B50 for ; Thu, 29 Apr 2010 08:19:06 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA280354294; Thu, 29 Apr 2010 17:18:14 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id RAA14922; Thu, 29 Apr 2010 17:18:13 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201004291518.RAA14922@TR-Sys.de> To: urn@ietf.org Date: Thu, 29 Apr 2010 17:18:13 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Subject: [urn] Focus of the discussion X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 15:19:21 -0000 Folks, I have listend to the discussion so far this week, and I appreciate its breadth and depth (and the range of contributors). However, we are not yet in a stage where technical details of the documents to be revised are ready for consensus-building. This will be the task of the WG, once established. So may I ask you to re-focus the discussion on the proposed charter? (See ). Of course, collecting facts and requirements from existing URN namespaces is encouraged as well, but we should prioritize now the necessary steps to have a sucessful BoF in Maastricht. The draft charter sketches three groups of work items and tries to give the direction of work. Let's take a look at these. AFAICS, there already seems to be rough consensus that the 'core' URN documents need updates, and that these updates need to be performed with a conservative attitude, but -- according to the basic principles of the IETF -- also taking into account experiences and "running code". The experiences that led to RFC 3986 are part of this 'knowledge'. Also, feedback from the ISSN authorities indicate that URN:ISSN indeed deserves a revised specification. So, with regard to the work already in progress, the three namespaces for bibliographic identifiers mentioned in the second group of work items in the initial draft charter (ISBN, NBN, and ISSN) indeed should be regarded as confirmed work items. Some of the discussion so far has scratched at the basic understanding of the role of URNs, and much of that is related to the third part of work suggested in the initial draft charter. So there seems to be interest in taking on work in this area as well. So please comment on the scope of the WG as envisioned in the draft charter, and on ways how it should be refined/improved. The most productive way to do so -- as always -- is to propose text snippets. Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From moore@network-heretics.com Thu Apr 29 13:59:05 2010 Return-Path: X-Original-To: urn@core3.amsl.com Delivered-To: urn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA4CC28C113 for ; Thu, 29 Apr 2010 13:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.24 X-Spam-Level: X-Spam-Status: No, score=0.24 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_50=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YydlwOus5FpW for ; Thu, 29 Apr 2010 13:59:05 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 1486B3A6A81 for ; Thu, 29 Apr 2010 13:59:05 -0700 (PDT) Received: from lust.indecency.org (174-151-122-31.pools.spcsdns.net [174.151.122.31]) by m1.imap-partners.net (MOS 4.1.8-GA) with ESMTP id BRB65633 (AUTH admin@network-heretics.com); Thu, 29 Apr 2010 13:58:44 -0700 X-Mirapoint-Received-SPF: 174.151.122.31 lust.indecency.org 5 none X-Mirapoint-Received-SPF: 174.151.122.31 lust.indecency.org 5 none X-Mirapoint-Received-SPF: 174.151.122.31 lust.indecency.org 5 none Message-ID: <4BD9F303.6080103@network-heretics.com> Date: Thu, 29 Apr 2010 16:58:43 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: =?UTF-8?B?QWxmcmVkIO+/vQ==?= References: <201004291518.RAA14922@TR-Sys.de> In-Reply-To: <201004291518.RAA14922@TR-Sys.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] Focus of the discussion X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 20:59:05 -0000 I am strongly of the opinion that the WG MUST be constrained from attempting to change the intent of the original URN specifications; or for that matter the specifications themselves except as necessary to clarify, correct errata, and reconcile apparent differences with other standards. History suggests that discussions about naming are very contentious. They seem to bring people out of the woodwork who want this kind of name to serve whatever purpose they hope to serve, whether or not that is the intent behind that kind of name. We had that problem with the original URN discussions. We also had that problem with discussions around "human friendly names" and similar ideas. To some degree we've even had that problems with discussions of URLs, and there is a long history of contention on use of DNS names. The battle for control of URNs needs to not be revisited. Those decisions have already been made, and they were hard fought. People who want URNs to be something significantly different than they were originally specified to be need to go elsewhere, or start from scratch to convince the community that a new kind of name is needed. This is especially important to preserve the persistence qualities of URNs. This needs to be made very clear in the group's charter, and right now there's not even a hint of that. Keith