From stpeter@stpeter.im Tue Jun 1 19:32:29 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 D6AD63A6920 for ; Tue, 1 Jun 2010 19:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.191 X-Spam-Level: X-Spam-Status: No, score=-0.191 tagged_above=-999 required=5 tests=[AWL=-0.192, 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 p6S+X82r31OC for ; Tue, 1 Jun 2010 19:32:28 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id C95E23A6835 for ; Tue, 1 Jun 2010 19:32:28 -0700 (PDT) Received: from squire.local (dsl-251-206.dynamic-dsl.frii.net [216.17.251.206]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8337F40E14 for ; Tue, 1 Jun 2010 20:32:15 -0600 (MDT) Message-ID: <4C05C2AE.30706@stpeter.im> Date: Tue, 01 Jun 2010 20:32:14 -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: "urn@ietf.org" 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="------------ms010100040706010104020805" Subject: [urn] draft of BoF agenda 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, 02 Jun 2010 02:32:30 -0000 This is a cryptographically signed message in MIME format. --------------ms010100040706010104020805 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Alfred has been working on an agenda for the proposed BoF at IETF 78, which I'm posting on this list (with some editorial changes by your friendly AD) mostly so that we can link to it from the BoF page here: http://trac.tools.ietf.org/bof/trac/wiki/WikiStart Alfred, feel free to post a modified version or to correct my edits, on or off the list. :) /psa ### Agenda for URNbis (URN) BoF IETF 78, Maastricht, NL ----------------------------------- State: Initial Draft Author: Alfred Hoenes Last Modified: 2010-05-26 BOF CHAIRS: (to be finalized / confirmed by ADs) John C. Klensin Alfred Hoenes AGENDA: (tailored for 1.5-hour slot) 1. Administrivia (Chairs, 10 min) - Note takers, Jabber scribes - Note Well - Agenda bashing 2. Presentations (40 min) - The need for up-to-date URN Standard documents (Juha Hakala, 15 min) - ISBN URNs (Juha Hakala, 5 min) - NBN URNs (TBD, 5 min) - ISSN URNs (TBD, 5 min) - URN Resolution systems and Project PersID (TBD, 10 min) 3. Open Q&A on presentations (Chairs, 15 min) 4. Discussion of Draft Charter (Chairs, 30 min) 5. Conclusions and Next Steps (Chairs/ADs, 10 min) ### --------------ms010100040706010104020805 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 hvcNAQkFMQ8XDTEwMDYwMjAyMzIxNFowIwYJKoZIhvcNAQkEMRYEFLZviqNEPMQXY4OA3g89 JWwH2MwvMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAmgIfPIPUM1AimR/PaexfbnTBqWldc5J3iCCmuee0 mIIpjMv5hV0woSvzXdS2pSFyG7COVSR8enaF5XhmAMTfxrUHrQ+rTP30iEroilBQUB43ZruT 05wD809JSqpZAd0pfhLTQzIbQ8IYUfq7zO+cITUnzNb/PY2gnsVKn4fpcGURg21SdDAi6/QX 0zCGkr2HzGJUOpqGFaZeSb9TF5A6iHkATE6VD5DuRWftaBvpsoZKmFko9yKlaEZ4uYei0qns le2s8veuQMkb7MuUgSAS3EtIEJCu2Btk4qrjCl1QnpcgaSzQwmSO90Tj2OEmbVjaVFydpVVw fU4Z/NsbOhnBogAAAAAAAA== --------------ms010100040706010104020805-- From A.Hoenes@TR-Sys.de Wed Jun 2 01:55:28 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 8E9BB3A698D for ; Wed, 2 Jun 2010 01:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.149 X-Spam-Level: X-Spam-Status: No, score=-96.149 tagged_above=-999 required=5 tests=[AWL=0.000, 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 T65wqeCukcgG for ; Wed, 2 Jun 2010 01:55:27 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 65E9028C123 for ; Wed, 2 Jun 2010 01:54:28 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA182758804; Wed, 2 Jun 2010 10:53:24 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id KAA08731; Wed, 2 Jun 2010 10:53:22 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201006020853.KAA08731@TR-Sys.de> To: urn@ietf.org Date: Wed, 2 Jun 2010 10:53:22 +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: Re: [urn] draft of BoF agenda 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, 02 Jun 2010 08:55:28 -0000 The draft URNbis BoF Agenda (dated 2010-05-26) that Peter has posted already has been superseded by an expanded version (dated 2010-05-28) that so far only has been circulated internally with the ADs. Work is in progress to align that 2010-05-28 version with the AD changes to the 2010-05-26 version, and so please expect an updated draft BoF Agenda soon. Kind regards, Alfred. From stpeter@stpeter.im Wed Jun 2 05:02: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 A899528C169 for ; Wed, 2 Jun 2010 05:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.616 X-Spam-Level: X-Spam-Status: No, score=-1.616 tagged_above=-999 required=5 tests=[AWL=0.683, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iE4z8XJnGOkg for ; Wed, 2 Jun 2010 05:02:17 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id AB79428C167 for ; Wed, 2 Jun 2010 05:02:17 -0700 (PDT) Received: from squire.local (dsl-251-206.dynamic-dsl.frii.net [216.17.251.206]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6352B40E14; Wed, 2 Jun 2010 06:02:04 -0600 (MDT) Message-ID: <4C06483B.4020906@stpeter.im> Date: Wed, 02 Jun 2010 06:02:03 -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: =?UTF-8?B?QWxmcmVkIO+/vQ==?= References: <201006020853.KAA08731@TR-Sys.de> In-Reply-To: <201006020853.KAA08731@TR-Sys.de> 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="------------ms090809090308030106030706" Cc: urn@ietf.org Subject: Re: [urn] draft of BoF agenda 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, 02 Jun 2010 12:02:18 -0000 This is a cryptographically signed message in MIME format. --------------ms090809090308030106030706 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/2/10 2:53 AM, Alfred =EF=BF=BD wrote: > The draft URNbis BoF Agenda (dated 2010-05-26) that Peter has posted=20 > > already has been superseded by an expanded version (dated 2010-05-28) > that so far only has been circulated internally with the ADs. >=20 > Work is in progress to align that 2010-05-28 version with the > AD changes to the 2010-05-26 version, and so please expect an > updated draft BoF Agenda soon. Thanks, Alfred. We don't need the final agenda immediately, but I think we'll work out something close to final this week. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms090809090308030106030706 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 hvcNAQkFMQ8XDTEwMDYwMjEyMDIwM1owIwYJKoZIhvcNAQkEMRYEFPzrvbXN6AfYxxGwLzud QJHw61lIMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEATSRMDAa/MS0oe5f5m9hqfUDHhW+bHNnh8JCtTvQ1 O7sISDhVqMvUdFWA3eDGCBxBGcP3G6knzUg11Yf2Zb/+7uMRAoXOQ9C1xfcmJKPvNdJ+cyfi aZPUSD6m/P8KMbFWNLXjrKYkpw8v89yEpyLlML1V3jEaElWZ7vZ+3sVXPVHOb7XoRZgY+Nkk sEzaY+r+k+sUcK3aZWfTcfrpIIOzK6APcW0k43nmsPtjxvfo2tbGGkizFDLY5c+Htpl0aA27 sXYhe3hLystvLYFiuPdTW0GA3Ryxa3/45vhDUVJUFhcQ89//otmT0fVgK4Fo977IF9N1/iNr FskzwfMVbLyYRAAAAAAAAA== --------------ms090809090308030106030706-- From stpeter@stpeter.im Wed Jun 2 09:56: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 AFAEC3A6872 for ; Wed, 2 Jun 2010 09:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.147 X-Spam-Level: X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[AWL=0.452, 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 JH4x5-amBQkA for ; Wed, 2 Jun 2010 09:56:03 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 4156F3A67E9 for ; Wed, 2 Jun 2010 09:56:03 -0700 (PDT) Received: from squire.local (dsl-251-206.dynamic-dsl.frii.net [216.17.251.206]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 257C640E14 for ; Wed, 2 Jun 2010 10:55:50 -0600 (MDT) Message-ID: <4C068D14.3080208@stpeter.im> Date: Wed, 02 Jun 2010 10:55:48 -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: "urn@ietf.org" 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="------------ms020309030105030404030109" Subject: [urn] BoF approved 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, 02 Jun 2010 16:56:04 -0000 This is a cryptographically signed message in MIME format. --------------ms020309030105030404030109 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In the joint meeting of the IAB and IESG just now, the URNbis BoF was approved for IETF 78 in Maastricht. Expect further discussion on this list to more clearly define the charter and agenda. One point raised on the call was a desire to reach out to those who worked on URN technologies the first time around, so I will engage in some outreach to make sure those folks are aware of this new work. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms020309030105030404030109 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 hvcNAQkFMQ8XDTEwMDYwMjE2NTU0OFowIwYJKoZIhvcNAQkEMRYEFDGDXw9D1SEe6p2w414U zIfFawy1MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAly/OLQzEk5aJJ/MWCq6ifuSzk0Gu+2qhjEOA+kXI PaCQJk5/C6K1CH8HOpUmqS6v07X2LBMVjX/5Kl7DJwxeFksnQbc3eb22MIlQLUpQzgj1+Jza cR2VMtG+n8bi6f58s3+yF5U8BydIRa4gp1TSrPxTffCtmcHZeWGlziaUOGFMTGLWzd3EwIfw Faqfq00LWbZmjLOR/Nx30YSWqa0yXE4ZJp04djML0HGyT4EFWdYft9Hh1ruM3Yjso2DyTAQv 0Ceo16mL2fJcVK8CIN9jZncrbd6AiqEwElxgj7QxiHxIru6pgPTd+1Y6Cu8aLJkRkfnWjMHS sm6si56H/U37/gAAAAAAAA== --------------ms020309030105030404030109-- From A.Hoenes@TR-Sys.de Wed Jun 2 13:17:27 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 894F428C169 for ; Wed, 2 Jun 2010 13:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.149 X-Spam-Level: X-Spam-Status: No, score=-96.149 tagged_above=-999 required=5 tests=[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 Y1veHmcgz1Ao for ; Wed, 2 Jun 2010 13:17:25 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id D2A703A6A4B for ; Wed, 2 Jun 2010 13:17:23 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA186399782; Wed, 2 Jun 2010 22:16:22 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id WAA09799; Wed, 2 Jun 2010 22:16:20 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201006022016.WAA09799@TR-Sys.de> To: urn@ietf.org Date: Wed, 2 Jun 2010 22:16:20 +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] Second draft of BoF Agenda 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, 02 Jun 2010 20:17:27 -0000 Below is a revised and expanded draft version of the URNbis BoF Agenda. It has been compiled from a working copy circulated last Friday, taking into account the AD changes to the original submission as established in . Comments and suggestions for improval are welcome, as always. Kind regards, Alfred. -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Agenda URNbis (URN) BoF IETF 78, Maastricht, NL ----------------------------------- State: Draft Author: Alfred HÎnes Last Modified: 2010-06-02 ----------------------------------- BOF CHAIRS (to be finalized / confirmed by ADs): John C. Klensin Alfred HÎnes DATE/TIME/VENUE: t.b.d. (during week of July 26-30, 2010) GOAL: to charter a new WG AGENDA: (tailored for 1.5-hour slot) 1. Administrivia (Chairs, 5 min) - Note takers, Jabber scribes - "Note Well" - Agenda bashing 2. Presentations (40-45 min, presenters to be nominated) 2.1. The need for up-to-date URN Standard documents - where do URNs come from, why do we need them - URN work in the IETF, from mid 1970's until today - what happened on a wider scale, regarding URIs - mismatches and inconsistencies, lack of maturity (10-15 min) 2.2. One URN "customer": - National library use of URNs - a short presentation of project PersID (5 min) 2.3. Work items -- problem statement and scope of work (25 min) a) general goals and non-goals (2 min) b) Core URN documents - formal specification / revision of RFC 2141 - namespace registration / revision of RFC 3406 (6 min) c) URN namespaces for bibliograpic identifier systems - ISBN URNs / revision of RFC 3187 - NBN URNs / revision of RFC 3188 - ISSN URNs / revision of RFC 3044 (6 min) d) Review of other URN namespaces - review existing namespace registration RFCs {with respect to RFC 3986 etc. and work in b) above} - point original registrants to issues / needs for update - take on work on revisions in WG (only upon rechartering) - serve as a voluntary forum of competence in support of new URN namespace registrants and IANA urn-nid expert (3 min) e) URN Resolution -- principles and systems - review existing RFCs for relevance and need for update - decide whether new URN resolution framework document is needed - BCP on use of HTTP for URN resolution - based on experience in Project PersID (6 min) f) staging of work, possible milestones, advancing of STD maturity (2 min) [ Recommended reading for BOF attendants: the "Introduction" sections (at least!) of the I-Ds listed in the draft charter ] 3. Open Q&A for presentations (Chairs, 15 min) 4. Discussion of Draft Charter (Chairs/ADs, 15 min) 5. Conclusions and Next Steps (Chairs/ADs, 10 min) -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ From l.svensson@d-nb.de Fri Jun 4 05:10:50 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 52C143A6983 for ; Fri, 4 Jun 2010 05:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.166 X-Spam-Level: ** X-Spam-Status: No, score=2.166 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, 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 dwf3-ymuNpji for ; Fri, 4 Jun 2010 05:10:48 -0700 (PDT) Received: from nordpol.ddb.de (nordpol.ddb.de [193.175.100.40]) by core3.amsl.com (Postfix) with SMTP id 4992D3A698D for ; Fri, 4 Jun 2010 05:10:46 -0700 (PDT) Received: from dbf-ex.AD.DDB.DE (unknown [10.69.63.214]) by nordpol.ddb.de (Postfix) with ESMTP id 05BA2D5D03; Fri, 4 Jun 2010 14:10:28 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.5 Date: Fri, 4 Jun 2010 14:10:27 +0200 Message-ID: <6DA97EFF2763174B8BDC409CA19729840B5503D0@dbf-ex.AD.DDB.DE> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Spam-Wahrscheinlichkeit=82][urn] A second cut at the Draft Charter for the proposed URNbis WG Thread-Index: Acr7gLHuvw3HQ90jRXSgbKLMexCfIwIPIKUQ References: <201005242034.WAA22059@TR-Sys.de> From: "Svensson, Lars" To: =?iso-8859-1?Q?Alfred_H=CEnes?= Cc: =?iso-8859-1?Q?Kett=2C_J=FCrgen?= , urn@ietf.org, =?iso-8859-1?Q?Sch=F6ning-Walter=2C_Christa?= Subject: Re: [urn] [Spam-Wahrscheinlichkeit=82] A second 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: Fri, 04 Jun 2010 12:10:53 -0000 In litteris suis de , Alfred H=CEnes <>scripsit: Dear Alfred, Thanks for the updated version. I have one major issue with the new = draft charter: > Uniform Resource Names (URNs) are location-independent, persistent > identifiers for information resources. If URNs can only be used for information resources, we have a problem = with e. g. urn:isbn and urn:issn namespaces, since ISBNs and ISSNs don't = identify information resources (at least not in the AWWW sense), but = rather abstract concepts (an ISBN identifies what the library community = refers to as a FRBR manifestation, i. e. -- informally spoken -- a = particular version of publication issued by a publisher). I'd suggest that we leave it open which kinds of resources can be = identified by URNs: [[ Uniform Resource Names (URNs) are location-independent, persistent = identifiers. ]] Thanks and all the best, Lars > Uniform Resource Names, Revised (URNbis) -- Draft Proposed WG Charter > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Administrivia > +++++++++++++ >=20 > Last Modified: 2010-05-20 [AH] >=20 > Chair(s): > o N.N. >=20 > Applications Area Director(s): > o Alexey Melnikov > o Peter Saint-Andre >=20 > Applications Area Advisor: > o N.N. >=20 > Mailing Lists: > o 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 >=20 > o Related lists (used for IANA registration procedures (BCP > 35/66): urn-nid@ietf.org, uri-review@ietf.org >=20 > Additional information will be available at: > http://tools.ietf.org/wg/___ >=20 >=20 > Description of Working Group > ++++++++++++++++++++++++++++ >=20 > * * * Problem Statement * * * >=20 > Uniform Resource Names (URNs) are location-independent, persistent > identifiers for information resources. >=20 > The RFCs defining URNs and services based on them were published > in 1997-2001, based on old (or even provisional) basic documents > on the concepts of URI, URL, and URN, and with almost no=20 > implementation experience. Since then, the URN system has gained > significant popularity, and many URN Namespaces have been defined > and registered with IANA. 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. However, the evolving > distributed, interlinked URN resolution system being built lacks a > fundament that is consistent in terminology and formal description > with present (Full) Internet Standards. >=20 > The core URN RFCs -- RFC 2141 (URN Syntax) and RFC 4306 (Namespace > Definition Mechanisms) -- were based on outdated framework documents. > For instance, all References in RFC 2141 point to "work in progress" > or documents that have been superseded at least once. > Most importantly, since RFC 2141 was published before even the > now-obsolete RFC 2396 was published, it is based on pre-2396 drafts > and should be updated for consistency with the contemporary URI > syntax and terminology reflected in STD 66, RFC 3986. Additionally, > since RFC 2141 predates RFC 2234, it uses for its syntax definitions > an early form of BNF, not the ABNF commonly used in the IETF (first > specified in RFC 2234, later evolved to the current STD 68, > RFC 5234). > All IANA considerations and procedures should now be based on the > terminology and rules laid down in BCP 26, RFC 5226. >=20 > The lack of a formal registration of the 'urn' URI scheme fosters > recurring discussions on what URNs are. Such formal registration > is needed to clarify that URNs are specific URIs (namely those using > the 'urn' URI scheme) and hence all general rules for URIs apply to > URNs, in addition to the common rules for all URNs and particular=20 > scheme-specific rules.=20 >=20 > Key bibliographic identifier standards are ISBN and ISSN, which are > based on ISO standards and cover books and serials, respectively. > These ISO standards were revised in 2007 to clarify and extend the > underlying namespaces; those changes should be reflected in the URN > definitions so as to enable use of the extended forms of these=20 > identifiers in URNs. For materials not covered by ISBN, ISSN, or > other formal standards, many national libraries and other > institutions apply National Bibliography Numbers (NBNs). Their usage > has increased a lot since a related URN namespace was specified in > RFC 3188, and the deployment has proven that more flexibility was > needed than provided by the RFC -- both for NBN syntax and for the > distributed management of these identifiers. Thus, there is a need > to revise these namespace registration to correctly reflect the > current state of the art.=20 >=20 > Other (early) URN namespace definitions should be screened to verify > their alignment with the existing and updated base identifier > standards and updated RFCs, and to give advice to registrants > in case mismatches/deficiencies were detected. >=20 > The elaborations on URN resolution in early RFCs predate large-scale > experience with URIs in general and URNs in particular, and they do > predate the consolidation of terms achieved in a joint W3C / IETF > collaboration (published for the IETF as RFC 3305). Hence there is > a need to revisit these Informational documents as well and provide > updates, if necessary. It also needs to be determined whether the > implementation experiences from project PersID (and other existing > URN resolution systems) deserve consolidation towards standardization > to further interoperability of services and service user > applications.=20 >=20 >=20 > * * * Objectives for the Working Group * * * >=20 > This working group is chartered to update the key RFCs describing the > URN system, including RFC 2141 (URN Syntax) and RFC 4306 (Namespace > Definition Mechanisms), update selected URN namespace specifications > including those for ISBN, NBN and ISSN, and to screen and update RFCs > describing URN resolution principles and practices. > For all document revisions, the stability of existing identifiers and > backward compatibility with previous specifications (as far > as possible > with respect to existing Full Standards) are of foremost importance. >=20 > 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 documents, all on the Standards-Track. These updates are > needed to provide a normative foundation and assure uniformity and > interoperability of the > URN assignment and resolution concepts and procedures at the > abstract level.=20 >=20 > Details and tasks (the WG will approach these tasks in roughly this=20 > order):=20 >=20 > a) Core URN specifications >=20 > 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 formal IANA registration for the 'urn' URI scheme using > the current template from BCP 35 (RFC 4395); > - a revised set of URN examples (the WG will determine whether the > granted persistence of URNs allows usage of concrete, real-life > URN examples -- as desired by implementers -- or whether a URN > "example" namespace should be created for this purpose); > - and an update of the sections describing how URNs are resolved =20 > in the Internet.=20 >=20 > 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).=20 >=20 > b) URN Namespace specifications >=20 > 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), > - RFC 3188 (URN Namespace for National Bibliography Numbers), and > - RFC 3044 (URN Namespace for International Serial Standard Number). >=20 > In all these cases, the respective identifier system and/or the > institutions and roles involved in their assignment and resolution > have evolved since these RFCs have been published (see below for a=20 > sketch). The global importance of these identifier systems makes it > highly desirable to have Standards-Track namespace definition > documents.=20 >=20 > In particular, the URN:ISBN namespace needs to be extended according > to the revision of the international ISBN standard, ISO 2108: A new > version of the ISBN standard was approved in 2007. Changes to the > standard were non-trivial, and a thorough revision of RFC 3187 was=20 > needed. The version -00 of the RFC 3187bis I-D has already been > submitted, and the staff of the ISBN International Centre has been > informed about the revision, supports this work, and already has > approved the technical changes contained in it. >=20 > The ISSN (International Standard Serial Name) system (ISO 3297) > underwent a thorough revision a few years ago. The new version of the > standard (2007) introduces ISSN-L (linking ISSN), which makes it > necessary to rethink the way in which URN:ISSNs are resolved, and to > update RFC 3044 accordingly. This work to revise RFC 3044 is being > performed in co-operation with the ISSN International Centre. >=20 > The NBN (National Bibliography Number) URN namespace was registered > (by RFC 3188) before the national libraries or other users were > actually using the URN system. Now that millions of URN:NBNs have > been assigned mainly to resources the national libraries have stored > in their digital archives, the WG will provide a revised namespace > definition RFC that accurately catches the ways in which URN:NBNs are > assigned and resolved in practice, and that is aligned with the basic > standards and the revised core URN specifications. >=20 > c) URN resolution and resolution mechanisms >=20 > 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 as required to align it with > contemporary IETF terminology and the state-of-the-art of URN=20 > resolution services.=20 >=20 > 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. Such BCP will be based on > experience from large-scale URN resolution projects, in particular > the European URN resolution infrastructure under construction in the > project PersID.=20 >=20 > 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. >=20 > d) Further work >=20 > The WG will offer advice to previous and new registrants of URN > namespaces. It will screen the legacy URN namespace definition > documents and will provide advice to their registrants regarding > necessary steps to bring these registrations in line with the > existing standards and the revised URN core specifications, and > regarding other issues, if such are found. >=20 > The WG can take on work to update well-established URN namespace > definitions other than the aforementioned cases of bibliographic > identifier based URN namespaces, upon a case-by-case decision, and > in collaboration with the respective original registrating party > (or its legitimate successor); doing so will require an update to=20 > this charter.=20 >=20 >=20 > WG Input / Output > +++++++++++++++++ >=20 > Input documents: >=20 > RFC 2141 > RFC 3406 >=20 > RFC 3187 > RFC 3188 > RFC 3044 >=20 > RFC 2483 > RFC 2276 > RFC 1737 > RFC 2169 >=20 > Goals and Milestones (rough and preliminary): >=20 > Dec 2010 WG Last Call on "core document set" ( a) + b) above ) > 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. >=20 > Internet-Drafts: >=20 > draft-ah-rfc2141bis-urn (-00: submitted March 2010) > draft-hakala-rfc3187bis-isbn-urn (-00: submitted March 2010) > draft-hakala-rfc3188bis-nbn-urn (-00: submitted May 2010) >=20 > Request For Comments: >=20 > none so far >=20 > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn --=20 Dr. Lars G. Svensson Deutsche Nationalbibliothek Informationstechnik Adickesallee 1 60322 Frankfurt http://www.d-nb.de/ From A.Hoenes@TR-Sys.de Fri Jun 4 11:51: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 8009B3A69A6 for ; Fri, 4 Jun 2010 11:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.35 X-Spam-Level: X-Spam-Status: No, score=-95.35 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_60=1, 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 1W8ehh7J5kYS for ; Fri, 4 Jun 2010 11:51:03 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 7B84C3A69CA for ; Fri, 4 Jun 2010 11:50:57 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA200577389; Fri, 4 Jun 2010 20:49:49 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id UAA13240; Fri, 4 Jun 2010 20:49:48 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201006041849.UAA13240@TR-Sys.de> To: l.svensson@d-nb.de Date: Fri, 4 Jun 2010 20:49:47 +0200 (MESZ) In-Reply-To: <6DA97EFF2763174B8BDC409CA19729840B5503D0@dbf-ex.AD.DDB.DE> from "Svensson, Lars" at Jun "4, " 2010 "02:10:27" pm X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Cc: J.Kett@d-nb.de, urn@ietf.org, c.schoening@d-nb.de Subject: Re: [urn] ... A second 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: Fri, 04 Jun 2010 18:51:04 -0000 At Fri, 4 Jun 2010 14:10:27 +0200, Lars Svensson wrote: > In litteris suis de , Alfred HÎnes <>scripsit: > > Dear Alfred, > > Thanks for the updated version. I have one major issue with the new > draft charter: > >> Uniform Resource Names (URNs) are location-independent, persistent >> identifiers for information resources. > > If URNs can only be used for information resources, we have a problem > with e. g. urn:isbn and urn:issn namespaces, since ISBNs and ISSNs > don't identify information resources (at least not in the AWWW sense), > but rather abstract concepts (an ISBN identifies what the library > community refers to as a FRBR manifestation, i. e. -- informally > spoken -- a particular version of publication issued by a publisher). > > I'd suggest that we leave it open which kinds of resources can be > identified by URNs: > > [[ > Uniform Resource Names (URNs) are location-independent, persistent > identifiers. > ]] Lars, thanks for your comments. Arguably, books and periodicals _are_ some kind of information ressources -- at least IMO. :-) But admittedly, the word "information" has slipped into the draft charter inadvertently from a comment received on the first cut, perhaps without much reflection. We have been told by wise men to not try to touch on the elaborate compromise wordings agreed upon during the creation of RFC 2141, for the definition of the nature and the aim of URNs, and we agree with that borderline -- because it makes sense, and it should help focus the intended work in the WG. Therefore, the related phrases in the rfc2141bis draft are copied literally from RFC 2141, and I agree that the charter should be consistent with that draft as well. So I'll follow your recommendation and adjust my working copy of the draft charter. > > Thanks and all the best, > > Lars > > >> Uniform Resource Names, Revised (URNbis) -- Draft Proposed WG Charter >> ======================================== >> (see original posting archived at ). >> > > -- > Dr. Lars G. Svensson > Deutsche Nationalbibliothek > Informationstechnik > Adickesallee 1 > 60322 Frankfurt > http://www.d-nb.de/ MfG / 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 masinter@gmail.com Mon Jun 7 09:50:53 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 6C3C23A65A6 for ; Mon, 7 Jun 2010 09:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.399 X-Spam-Level: X-Spam-Status: No, score=-99.399 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCCmEeOvs-iD for ; Mon, 7 Jun 2010 09:50:52 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 7C04D3A8BBD for ; Sun, 6 Jun 2010 11:42:26 -0700 (PDT) Received: by pvf33 with SMTP id 33so1388178pvf.31 for ; Sun, 06 Jun 2010 11:42:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language :x-cr-hashedpuzzle:x-cr-puzzleid; bh=2e/Xr/CKG0wb7MtevsM2FiLY/Gnh0y/n4hQohbyX1fU=; b=u5lFirsAtdT/NYPgvisu6C0MS6OwInHlpgqnSwQLXlEmXvZmKMCBntpDxPtvSL076X AfzjSD/FSAC4W9PA890bgw9bhL+8Q69H/0DCu0devCDhheTVlkmdSEpcrxEDiwnuNORY 1xVzDDAmDx6RXrmY6DQDxDBgzp+YWpLmIlFOQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-cr-hashedpuzzle:x-cr-puzzleid; b=OcFdLuW1h5dyJFaParScvQhAGwyKRzi1QjCDV3EyaZTWNAgZaRBI0l5WigYcpx7SZu cO1sCkF7nLRNG/rI0Q5+AXgMoArsex5mk339kb9o1Vy1UuLVyOUs4llx6+niXxkhOQ3d vFxLO1hhji3o6omqwIcqKzz2NqDmVH/ls3Y7o= Received: by 10.115.103.40 with SMTP id f40mr10833486wam.38.1275849744085; Sun, 06 Jun 2010 11:42:24 -0700 (PDT) Received: from MASINTERXP (c-98-207-107-29.hsd1.ca.comcast.net [98.207.107.29]) by mx.google.com with ESMTPS id 33sm31131606wad.8.2010.06.06.11.42.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 06 Jun 2010 11:42:23 -0700 (PDT) Sender: Larry Masinter From: "Larry Masinter" To: References: In-Reply-To: Date: Sun, 6 Jun 2010 11:42:23 -0700 Message-ID: <000001cb05a8$017f5dc0$047e1940$@org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsFnnXUEcNLf6eSS3u4hpep7eJ7TwABHVIw Content-Language: en-us x-cr-hashedpuzzle: ww8= Axrc A+Gh BpOt B3pe CuaB DfPL DnZK EXD5 FAEi Ic50 IjVM Jn+8 K0Bo K0lD LScQ; 1; dQByAG4AQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {67F2A4E7-4DF1-4A43-BCF1-8F6B379B1097}; bABtAG0AQABhAGMAbQAuAG8AcgBnAA==; Sun, 06 Jun 2010 18:42:19 GMT; cABlAHIAaABhAHAAcwAgAGEAIABkAGkAZgBmAGUAcgBlAG4AdAAgAHAAZQByAHMAcABlAGMAdABpAHYAZQAgAG8AbgAgAFUAUgBOAHMAPwA= x-cr-puzzleid: {67F2A4E7-4DF1-4A43-BCF1-8F6B379B1097} X-Mailman-Approved-At: Mon, 07 Jun 2010 09:59:05 -0700 Subject: [urn] perhaps a different perspective on URNs? 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: Mon, 07 Jun 2010 16:50:53 -0000 I wouldn't mind helping with some of the history and current issues. http://masinter.blogspot.com/2010/03/resources-are-angels-urls-are-pin s.html http://www.w3.org/Bugs/Public/show_bug.cgi?id=8116 My recent thinking on URNs is that the properties of "location-independent" and "persistent" are not (or should not be) the key distinguishing feature of URNs vs any other kind of URI. Rather, what makes sense to me best is to note that URNs are primarily distinguished by the reliance on an authority -- some organization, consortium, informal alliance, collective -- which maintains the correspondence between URNs and the resources they name. These authorities offer or promise different kinds of service guarantees for being able to resolve the URN than might be available using traditional internet methods that rely on DNS and its administration. Observation: urn:uuid was a mistake, but most of the other URN namespaces seem to fit this definition quite well. Larry From A.Hoenes@TR-Sys.de Tue Jun 8 11:59: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 42EF53A68E3 for ; Tue, 8 Jun 2010 11:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.549 X-Spam-Level: X-Spam-Status: No, score=-95.549 tagged_above=-999 required=5 tests=[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 neM9Ycwh-jVG for ; Tue, 8 Jun 2010 11:59:10 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 57ECA3A67D9 for ; Tue, 8 Jun 2010 11:59:09 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA222083494; Tue, 8 Jun 2010 20:58:14 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id UAA19595; Tue, 8 Jun 2010 20:58:13 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201006081858.UAA19595@TR-Sys.de> To: LMM@acm.org Date: Tue, 8 Jun 2010 20:58:12 +0200 (MESZ) In-Reply-To: <000001cb05a8$017f5dc0$047e1940$@org> from Larry Masinter at Jun "6, " 2010 "11:42:23" 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] perhaps a different perspective on URNs? 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, 08 Jun 2010 18:59:11 -0000 Larry Masinter wrote: > I wouldn't mind helping with some of the history > and current issues. > > http://masinter.blogspot.com/2010/03/resources-are-angels-urls-are-pins.html > http://www.w3.org/Bugs/Public/show_bug.cgi?id=8116 Thanks for these pointers. However, I'm not sure this discussion helps much wrt the primary goals we have of arriving at basic documents on URNs that can be advanced on the maturity ladder of the IETF Standards Track. > My recent thinking on URNs is that the properties of > "location-independent" and "persistent" are not (or should > not be) the key distinguishing feature of URNs vs any > other kind of URI. > > Rather, what makes sense to me best is to note that URNs > are primarily distinguished by the reliance on an authority -- > some organization, consortium, informal alliance, collective -- > which maintains the correspondence between URNs and the resources > they name. > > These authorities offer or promise different kinds of service > guarantees for being able to resolve the URN than might be > available using traditional internet methods that rely on DNS > and its administration. Interesting note. See more thoughts and comments below. > Observation: > urn:uuid was a mistake, but most of the other URN namespaces > seem to fit this definition quite well. So you are saying that's precisely why the 'geo' URI scheme (RFC 5870, just published) didn't make it as a URN namespace? Back to the main remark: However, it seems important to observe that "persistent" and "reliance on a renowned authority" (attribute added, tempted to prefix "well-" as well!) are very closely related. The proposed registration template for the 'urn' URI scheme I have drafted in Section 7.1 of draft-ah-rfc2141bis-urn contains the following fundamental clause: URI scheme semantics: 'urn' URIs, known as Universal Resource Names (URNs), serve as persistent, location-independent, resource identifiers for concrete and abstract objects that have network accessible instances and/or metadata. URNs are structured hierarchically into URN Namespaces, the management of which is delegated to namespace-specific authorities. Each such URN namespace is founded in an independent specification and registered with IANA, following the guidelines and procedures of BCP 66 (at the time of this registration: RFC 3406). Doesn't that clause already capture at least some smell of your considerations? Should we add in the 2nd paragraph: authorities _that maintain the uniqueness and persistence of these identifiers_. [...] ? Please also note the shift of emphasis from the opalescent term "resource" to "concrete and abstract objects". The former has been retained to remain close to RFC 2141 (et al.), but eventually it could be dropped entirely from this clause. Alfred. > > Larry From tommi.jauhiainen@helsinki.fi Fri Jun 11 05:32:29 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 CB92228C17C for ; Fri, 11 Jun 2010 05:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TiQfbEyK93kU for ; Fri, 11 Jun 2010 05:32:22 -0700 (PDT) Received: from slay.it.helsinki.fi (slay.it.helsinki.fi [128.214.205.48]) by core3.amsl.com (Postfix) with ESMTP id 06F1028C180 for ; Fri, 11 Jun 2010 05:32:16 -0700 (PDT) Received: from slay.it.helsinki.fi (slay.it.helsinki.fi [128.214.205.48]) by slay.it.helsinki.fi (8.13.1/8.13.1) with ESMTP id o5BCWDd1001480; Fri, 11 Jun 2010 15:32:13 +0300 Received: from vapaa-3.lib.helsinki.fi (vapaa-3.lib.helsinki.fi [128.214.71.204]) (authenticated bits=0) by smtp-rs2.it.helsinki.fi (8.13.8/8.13.8) with ESMTP id o5BCWD6S009446 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 11 Jun 2010 15:32:13 +0300 Message-Id: <2CF23501-B15E-45DB-A9BA-A98CCB0C361B@helsinki.fi> From: Tommi Jauhiainen To: urn@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-316--547893477 Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 11 Jun 2010 15:32:13 +0300 X-Mailer: Apple Mail (2.936) X-HY-Tests: ALL_TRUSTED,SHORTCIRCUIT Cc: Tommi Jauhiainen Subject: [urn] Comments on rfc3188bis 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: Fri, 11 Jun 2010 12:32:29 -0000 --Apple-Mail-316--547893477 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hi all, I have some comments, questions and suggestions to and about the draft =20= and I'll go through them in order of appearance in the draft. --- Chapter 3 says: "As a rule, NBNs identify finite, manageably-sized objects, but these =20= objects may still be large enough that resolution into a hierarchical =20= system is appropriate." I find the definition of size as "manageably-sized" very vague. How =20 about something like this? (I left the "as a rule" out from the =20 beginning as well). "NBNs identify finite objects, but sometimes these objects might be so =20= large that resolution into a hierarchical system is appropriate." --- In chapter 4.1. it says: "National Bibliography Number (NBN) is a generic name referring to a =20 group of identifier systems utilised by the national libraries and =20 institutions authorized by them, such as universities." First I wanted to reduce repetition by removing the ", such as =20 universities" away from the end, as in the previous chapter it has =20 just been declared that: "National libraries may however allow other organizations such as university libraries or governmental organizations to assign NBNs to their resources." Then I started to ponder about the usage of "utilised" and =20 "assigning". Could we use a word like "administer" instead of =20 "utilise" and "use" when referring to NBNs as a system? For example I tried to rephrase the first section of 4.1: "National Bibliography Number (NBN) is a generic name referring to a =20 group of identifier systems administered by the national libraries. =20 The NBNs are assigned to resources by the national libraries and =20 institutions authorized by them. These institutions should be =20 committed to preserve their collections for a long time; at least =20 decades and possibly centuries." --- Chapter 4.1 says: "URNs may also be used in universities' open repositories when a =20 resource already has another identifier -- often a DOI (Digital Object =20= Identifier) -- that can only be resolved in a publisher's (or third =20 party's) resolution service, which cannot be used to provide linking =20 to the open repository. URN:NBN-based resolution can deliver that, =20 and may also be extended to include access to other repositories =20 holding the same resource." I believe that this isn't technically correct. Maybe the whole section =20= could be left out? --- In Chapter 4.2. there is an example of: "For instance, the national library of Finland has given Statistics =20 Finland () a sub-namespace =20 "st" (i.e., urn:nbn:fi:st)." I'd change that example to some other sub-namespace as it happens that =20= the Statistics Finland has never really used the given namespace. For =20= example: "For instance, the national library of Finland has given the =20 University of Jyv=E4skyl=E4 () a sub-namespace =20 "jyu" (i.e., urn:nbn:fi:jyu)." I think that this example could be left out from 4.2.: "(NBN assigned to Tero Frestadius's Master's Thesis "In and Out": =20 Segmentary Gang Politics in Los Angeles)." --- In 4.3. it says: "URNs can be used to provide various services. RFC 2483 [RFC2483] =20 gives a few examples, such as retrieving a single URL or all URLs =20 applying to the resource. Services available may vary, depending on =20 the technical implementation of the URN resolver and the target system =20= contacted. Please note that services must not be hard codedinto the =20 URN itself." This "hard coding" is not defined anywhere and is too general as it =20 is. I believe this doesn't mean MUST must but perhaps SHOULD? --- In 4.3. also: "Eventually, URNs will be resolved with the help of a resolver =20 discovery service (RDS). However, no such system is widely available =20= yet." Is such system available at all at the moment? (which would work =20 without embedding URNs into HTTP URIs) If not really, then we perhaps =20= should leave that remark out? --- One more example correction suggestion in 4.3: "Thus the HTTP URI for the URN in the example is = . This in turn resolves to the actual address of the thesis, which =20= as of this writing (2010-03-27) was = ." The urn actually resolves to the splash-page of the thesis: = . --- Chapters 4.5. and 5. are the same. I believe it is the intention to =20 leave the 4.5. out? --- The formal declaration of the NSS in 4.6. is supposed to be RFC5234 =20 compliant but still uses the obsolete (mentioned in RFC 3986) rule =20 "ALPHANUM" in definitions: " subspc =3D 1*ALPHANUM ; as assigned by the respective national library reg_prefix =3D 3*ALPHANUM ; as assigned by the Library of Congress -- ; identifies a trusted third party ; to which the bracnh is delegated" Correct way is now "( ALPHA / DIGIT )" instead of "ALPHANUM" so: " subspc =3D 1*( ALPHA / DIGIT ) ; as assigned by the respective national library reg_prefix =3D 3*( ALPHA / DIGIT ) ; as assigned by the Library of Congress -- ; identifies a trusted third party ; to which the bracnh is delegated" --- I don't remember seeing the reasoning behind this prohibition in 4.6.: "Dividing non-ISO 3166-based namespaces further with sub-namespace =20 codes MUST NOT be done." Would you care to enlighten me why this MUST NOT exists in the first =20 place? --- Cheers, Tommi --=20 Tommi Jauhiainen (Mr.) Information Systems Specialist Tietoj=E4rjestelm=E4asiantuntija The National Library of Finland Kansalliskirjasto PL 26 (Teollisuuskatu 23) http://www.kansalliskirjasto.fi/ 00014 University of Helsinki Tel. +358 50 415 0 555 --Apple-Mail-316--547893477 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

I have some comments, questions and = suggestions to and about the draft and I'll go through them in order of = appearance in the draft.

---

Chapter 3 says:
"As a rule, NBNs identify finite, = manageably-sized objects, but these objects may still be large = enough that resolution into a hierarchical system is = appropriate."
 
I find the definition of = size as "manageably-sized" very vague. How about something like this? (I = left the "as a rule" out from the beginning as well).

"NBNs identify finite = objects, but sometimes these objects might be so large that resolution = into a hierarchical system is appropriate."

---

In chapter 4.1. it = says:
"National Bibliography Number (NBN) is a generic name referring to = a group of identifier systems utilised by the national libraries and = institutions authorized by them, such as = universities."

First I wanted to =
reduce repetition by removing the ", such as universities" away from the =
end, as in the previous chapter it has just been declared =
that:

"National =
libraries may however allow other
   organizations such as university libraries or governmental
   organizations to assign NBNs to their =
resources."

Then I started to =
ponder about the usage of "utilised" and "assigning". Could we use a =
word like "administer" instead of "utilise" and "use" when referring to =
NBNs as a system? 

For example I =
tried to rephrase the first section of 4.1:

"National =
Bibliography Number (NBN) is a generic name referring to a group of =
identifier systems administered by the national libraries. The NBNs are =
assigned to resources by the national libraries and institutions =
authorized by them. These institutions should be committed to preserve =
their collections for a long time; at least decades and possibly =
centuries."

---

Chapter 4.1 =
says:
"URNs may also be used in universities' open =
repositories when a resource already has another identifier -- =
often a DOI (Digital Object Identifier) -- that can only be =
resolved in a publisher's (or third party's) =
resolution service, which cannot be used to provide =
linking to the open repository.  URN:NBN-based resolution can deliver =
that, and may also be extended to include =
access to other repositories holding the same =
resource."

I believe that = this isn't technically correct. Maybe the whole section could be left = out?

---

In Chapter 4.2. = there is an example of:
"For instance, the = national library of Finland has given Statistics Finland = (<http://www.stat.fi/index_en.html>) a = sub-namespace "st" (i.e., urn:nbn:fi:st)."

I'd change that = example to some other sub-namespace as it happens that the Statistics = Finland has never really used the given namespace. For = example:

"For instance, the = national library of Finland has given the University of = Jyv=E4skyl=E4 (<http://www.jyu.fi/>) a = sub-namespace "jyu" (i.e., urn:nbn:fi:jyu)."


I think that this example could be left out = from 4.2.:
"(NBN assigned to Tero Frestadius's Master's = Thesis "In and Out": Segmentary Gang Politics in Los = Angeles)."

---

In 4.3. it = says:
"URNs can be used to provide various services. = RFC = 2483 = [RFC2483] gives a few = examples, such as retrieving a single URL or all URLs = applying to the resource. Services available = may vary, depending on the technical = implementation of the URN resolver and the target system contacted. = Please note that services must not be hard = codedinto the URN = itself."

This "hard coding" is not defined anywhere = and is too general as it is. I believe this doesn't mean MUST must but = perhaps SHOULD?

---

In 4.3. = also:
"Eventually, URNs will be resolved with the = help of a resolver discovery service (RDS).  However, no such = system is widely available yet."

Is such system available at all at the = moment? (which would work without embedding URNs into HTTP URIs) If not = really, then we perhaps should leave that remark = out?

---

One more example = correction suggestion in 4.3:
"Thus the HTTP URI = for the URN in the example is <http://urn.fi/URN:NBN:fi-fe201003181510>.  This = in turn resolves to the actual address of the thesis, which as of = this writing (2010-03-27) was <https://oa.doria.fi/bitstream/handle/10024/59475/= inandout.pdf?sequence=3D1>."

The urn actually resolves to the splash-page = of the thesis: <https://oa.doria.fi/handle= /10024/59475>.

---

Chapters 4.5. and 5. are the same. I believe = it is the intention to leave the 4.5. out?

---

The formal declaration of the NSS in 4.6. is = supposed to be RFC5234 compliant but still uses the obsolete (mentioned = in RFC 3986) rule "ALPHANUM" in = definitions:
" subspc      =3D = 1*ALPHANUM
   =                     ; = as assigned by the respective national library

         = reg_prefix  =3D 3*ALPHANUM
   =                     ; = as assigned by the Library of Congress --
             =           ; to which the bracnh is = delegated"

Correct way is now "( ALPHA / DIGIT )" = instead of "ALPHANUM" so:

" subspc      =3D 1*( = ALPHA / DIGIT )
   =                     ; = as assigned by the respective national library

         = reg_prefix  =3D 3*( ALPHA / DIGIT )
             =           ; identifies a trusted third = party
         =               ; to which the bracnh = is delegated"

---

I don't remember seeing the reasoning behind = this prohibition in 4.6.:
"Dividing non-ISO = 3166-based namespaces further with sub-namespace codes MUST NOT be = done."

Would you care to = enlighten me why this MUST NOT exists in the first = place?

---

Cheers,
Tommi
-- 
Tommi Jauhiainen = (Mr.)

Information Systems Specialist = = Tietoj=E4rjestelm=E4asiantuntija
The National Library of = Finland = = Kansalliskirjasto

PL 26 (Teollisuuskatu = 23) = = http://www.kansalliskirjasto.fi/
00014 = University of Helsinki = Tel. +358 50 415 0 555


 =

= --Apple-Mail-316--547893477-- From juha.hakala@helsinki.fi Fri Jun 11 06:25:15 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 CF3963A69C6 for ; Fri, 11 Jun 2010 06:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bf-2fnvsHyZR for ; Fri, 11 Jun 2010 06:25:13 -0700 (PDT) Received: from slay.it.helsinki.fi (slay.it.helsinki.fi [128.214.205.48]) by core3.amsl.com (Postfix) with ESMTP id 0EA8E3A6830 for ; Fri, 11 Jun 2010 06:25:11 -0700 (PDT) Received: from slay.it.helsinki.fi (slay.it.helsinki.fi [128.214.205.48]) by slay.it.helsinki.fi (8.13.1/8.13.1) with ESMTP id o5BDP7kE022765; Fri, 11 Jun 2010 16:25:07 +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 o5BDLJbs018726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 11 Jun 2010 16:21:19 +0300 Message-ID: <4C12384E.8090508@helsinki.fi> Date: Fri, 11 Jun 2010 16:21:18 +0300 From: Juha Hakala User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Tommi Jauhiainen References: <2CF23501-B15E-45DB-A9BA-A98CCB0C361B@helsinki.fi> In-Reply-To: <2CF23501-B15E-45DB-A9BA-A98CCB0C361B@helsinki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HY-Tests: ALL_TRUSTED,SHORTCIRCUIT Cc: urn@ietf.org, Norman Paskin Subject: Re: [urn] Comments on rfc3188bis 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: Fri, 11 Jun 2010 13:25:15 -0000 Hello Tommi, Thank you for comments. Please see the responses below. Tommi Jauhiainen wrote: > Hi all, > > I have some comments, questions and suggestions to and about the draft > and I'll go through them in order of appearance in the draft. > > --- > > Chapter 3 says: > "As a rule, NBNs identify finite, manageably-sized objects, but > these objects may still be large enough that resolution into a > hierarchical system is appropriate." > > I find the definition of size as "manageably-sized" very vague. How > about something like this? (I left the "as a rule" out from the > beginning as well). > > "NBNs identify finite objects, but sometimes these objects might be so > large that resolution into a hierarchical system is appropriate." Your sentence is better than the original. And I agree that manageably-sized is a vague concept and should be removed from the text. > > --- > > In chapter 4.1. it says: > "National Bibliography Number (NBN) is a generic name referring to a > group of identifier systems utilised by the national libraries and > institutions authorized by them, such as universities." > > First I wanted to reduce repetition by removing the ", such as universities" away from the end, as in the previous chapter it has just been declared that: > > "National libraries may however allow other > organizations such as university libraries or governmental > organizations to assign NBNs to their resources." > > Then I started to ponder about the usage of "utilised" and "assigning". Could we use a word like "administer" instead of "utilise" and "use" when referring to NBNs as a system? I'm not sure. Need to think about this a bit. However,... > > > For example I tried to rephrase the first section of 4.1: > > " National Bibliography Number (NBN) is a generic name referring to a group of identifier systems administered by the national libraries. The NBNs are assigned to resources by the national libraries and institutions authorized by them. These institutions should be committed to preserve their collections for a long time; at least decades and possibly centuries." ...this feels OK. But I feel we should strengthen the wording that relates to the organisational commitment to preserve resources for future generations by stating that these organisation must be committed to preserve their collections for a long time. > > --- > > Chapter 4.1 says: > > " URNs may also be used in universities' open repositories when a resource already has another identifier -- often a DOI (Digital Object Identifier) -- that can only be resolved in a publisher's (or third party's) resolution service, which cannot be used to provide linking to the open repository. URN:NBN-based resolution can deliver that, and may also be extended to include access to other repositories holding the same resource." > > > I believe that this isn't technically correct. Maybe the whole section > could be left out? This section relates to the author's past belief that if a resource has a DOI, it might be difficult or even impossible to use this DOI as a means for resolving both to the URL of the publisher's copy of the resource and to the URL of the copy in the university's open repository. We need to check from DOI experts if a DOI can resolve to multiple URLs and if so, if the publishers are likely to allow adding links to the resources held in open repositories to their DOI resolution services. As I see it there is nothing wrong with a single resource such as a digital manifestation of a book having single ISBN but multiple persistent identifiers (DOI, URN or something else) which all resolve to different digital items. Given that large portions of the text in RFC 3188bis remain in original form there may be statements there that are by now out of date and must be edited or removed. > > --- > > In Chapter 4.2. there is an example of: > "For instance, the national library of Finland has given > Statistics Finland (< http://www.stat.fi/index_en.html >) a > sub-namespace "st" (i.e., urn:nbn:fi:st) ." > > I'd change that example to some other sub-namespace as it happens that > the Statistics Finland has never really used the given namespace. For > example: > > "For instance, the national library of Finland has given the University > of Jyväskylä (< http://www.jyu.fi/ >) > a sub-namespace "jyu" (i.e., urn:nbn:fi:jyu) ." OK. It would be nice to have real examples of sub-namespaces from other countries (Italy, perhaps?). > > > I think that this example could be left out from 4.2.: > "(NBN assigned to Tero Frestadius's Master's Thesis "In and > Out": Segmentary Gang Politics in Los Angeles)." I wanted to show what a real NBN-based URN actually looks like when used as a hyperlink. But should we drop the example? > > --- > > In 4.3. it says: > " URNs can be used to provide various services. RFC 2483 > [ RFC2483 > ] gives a few examples, such as > retrieving a single URL or all URLs applying to the resource. Services > available may vary, depending on the technical implementation of the URN > resolver and the target system contacted. Please note that services must > not be hard coded into the URN itself. " > > This "hard coding" is not defined anywhere and is too general as it is. > I believe this doesn't mean MUST must but perhaps SHOULD? No, I meant MUST. What hard coding means here is that there would be multiple URNs for a resource, each one providing a single service. A base version would resolve to the resource itself. With another version the user would get the bibliographic record, while yet another would facilitate retrieval of a list of URLs, and so on. I suppose this is one of the points which may become implementation issues. If there is only one URN, then there should be some other way in which the applications agree on what service is being called for. And there does not seem to be anything widely implemented in place we could use in e.g. PersID. > --- > > In 4.3. also: > "Eventually, URNs will be resolved with the help of a resolver discovery > service (RDS). However, no such system is widely available yet." > > Is such system available at all at the moment? (which would work without > embedding URNs into HTTP URIs) If not really, then we perhaps should > leave that remark out? If my memory serves me right, an experimental DNS-based solution was built, but it was only ever supported via a plug-in in browsers. It is definitely true that there is no widely available resolver discovery services in place at the moment, but I did not want to give an impression that nothing has been done. > > --- > > One more example correction suggestion in 4.3: > "Thus the HTTP URI for the URN in the example is < > http://urn.fi/URN:NBN:fi-fe201003181510 >. This in turn resolves to the > actual address of the thesis, which as of this writing (2010-03-27) was > < https://oa.doria.fi/bitstream/handle/10024/59475/ > inandout.pdf?sequence=1>." > > The urn actually resolves to the splash-page of the thesis: > . Do we need to provide this somewhat embarrassing detail ;-)? > > --- > > Chapters 4.5. and 5. are the same. I believe it is the intention to > leave the 4.5. out? Can we leave some vital things out from the namespace registration request, and rely on people finding the information from other parts of the RFC (or vice versa)? Replication in the current text is intentional, but can be eliminated if that's the majority view. > --- > > The formal declaration of the NSS in 4.6. is supposed to be RFC5234 > compliant but still uses the obsolete (mentioned in RFC 3986) rule > "ALPHANUM" in definitions: > " subspc = 1*ALPHANUM > ; as assigned by the respective national library > > reg_prefix = 3*ALPHANUM > ; as assigned by the Library of Congress -- > ; identifies a trusted third party > ; to which the bracnh is delegated" > > Correct way is now "( ALPHA / DIGIT )" instead of "ALPHANUM" so: > > " subspc = 1*( ALPHA / DIGIT ) > ; as assigned by the respective national library > > reg_prefix = 3*( ALPHA / DIGIT ) > ; as assigned by the Library of Congress -- > ; identifies a trusted third party > ; to which the bracnh is delegated" Alfred Hoenes is better qualified than myself to respond to this. > > --- > > I don't remember seeing the reasoning behind this prohibition in 4.6.: > "Dividing non-ISO 3166-based namespaces further with sub-namespace codes > MUST NOT be done." > > Would you care to enlighten me why this MUST NOT exists in the first place? Yes. When an ISO 3166 namespace is subdivided, then according to the RFC 3188 the national library in question must maintain the registry of these sub-namespaces. For non-ISO 3166 namespaces RFC 3188 states that there will be only one list, maintained by the Library of Congress (to my knowledge no such namespaces have been assigned yet, and it is not clear if there will be a demand for them). We do not know what kind of organisations would register these namespaces for themselves, and whether they would be willing to take the responsibility of maintaining a registry of sub-divisions of their namespace. For the sake of simplicity I thought that it would be better to just ban sub-division of these namespaces. Best regards, Juha > > --- > > Cheers, > Tommi > -- > Tommi Jauhiainen (Mr.) > > Information Systems Specialist Tietojärjestelmäasiantuntija > The National Library of Finland Kansalliskirjasto > > PL 26 (Teollisuuskatu 23) http://www.kansalliskirjasto.fi/ > 00014 University of Helsinki Tel. +358 50 415 0 555 > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 A.Hoenes@TR-Sys.de Sun Jun 20 12:39: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 20A7F3A69E8 for ; Sun, 20 Jun 2010 12:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.074 X-Spam-Level: X-Spam-Status: No, score=-96.074 tagged_above=-999 required=5 tests=[AWL=0.075, 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 ODXEVYc1lLOk for ; Sun, 20 Jun 2010 12:39:45 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 6123D3A68D0 for ; Sun, 20 Jun 2010 12:39:43 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA296302733; Sun, 20 Jun 2010 21:38:53 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id VAA09496; Sun, 20 Jun 2010 21:38:51 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201006201938.VAA09496@TR-Sys.de> To: juha.hakala@helsinki.fi, tommi.jauhiainen@helsinki.fi Date: Sun, 20 Jun 2010 21:38:50 +0200 (MESZ) In-Reply-To: <4C12384E.8090508@helsinki.fi> from Juha Hakala at Jun "11, " 2010 "04:21:18" pm 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, n.paskin@tertius.ltd.uk Subject: Re: [urn] Comments on rfc3188bis 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: Sun, 20 Jun 2010 19:39:49 -0000 On Jun 11, Juha hakal wrote: > Hello Tommi, > > Thank you for comments. Please see the responses below. Juha has said most, I think. Please see the solicited response inline below. > > Tommi Jauhiainen wrote: >> Hi all, >> >> I have some comments, questions and suggestions to and about the draft >> and I'll go through them in order of appearance in the draft. >> >> --- >> ... [snip] > >> --- >> >> In Chapter 4.2. there is an example of: >> "For instance, the national library of Finland has given >> Statistics Finland (< http://www.stat.fi/index_en.html >) a >> sub-namespace "st" (i.e., urn:nbn:fi:st) ." >> >> I'd change that example to some other sub-namespace as it happens that >> the Statistics Finland has never really used the given namespace. For >> example: >> >> "For instance, the national library of Finland has given the University >> of Jyväskylä (< http://www.jyu.fi/ >) >> a sub-namespace "jyu" (i.e., urn:nbn:fi:jyu) ." > > OK. It would be nice to have real examples of sub-namespaces from other > countries (Italy, perhaps?). We have a specific objective in the draft URNbis WG charter: Discussion of the kind and style of examples in the documents to be produced by the WG, whether these should be concrete or theoretical examples, perhaps using dedicated example namespaces (which the IESG strongly enforces for example domain names and IP addresses in RFCs). Please revisit the posted draft charter for context. > >> I think that this example could be left out from 4.2.: >> "(NBN assigned to Tero Frestadius's Master's Thesis "In and >> Out": Segmentary Gang Politics in Los Angeles)." > > I wanted to show what a real NBN-based URN actually looks like when > used as a hyperlink. But should we drop the example? > >> --- >> ... [snip] > >> >> --- >> >> Chapters 4.5. and 5. are the same. I believe it is the intention to >> leave the 4.5. out? > > Can we leave some vital things out from the namespace registration > request, and rely on people finding the information from other parts of > the RFC (or vice versa)? Replication in the current text is intentional, > but can be eliminated if that's the majority view. Every RFC needs to have a distinguished "Security Considerations" section. The registration template can refer to that section as it may for other required information. That's standing practice. So I agree 4.5 could be replaced by a short sentence pointing to 5. > >> --- >> >> The formal declaration of the NSS in 4.6. is supposed to be RFC5234 >> compliant but still uses the obsolete (mentioned in RFC 3986) rule >> "ALPHANUM" in definitions: >> " subspc = 1*ALPHANUM >> ; as assigned by the respective national library >> >> reg_prefix = 3*ALPHANUM >> ; as assigned by the Library of Congress -- >> ; identifies a trusted third party >> ; to which the bracnh is delegated" >> >> Correct way is now "( ALPHA / DIGIT )" instead of "ALPHANUM" so: >> >> " subspc = 1*( ALPHA / DIGIT ) >> ; as assigned by the respective national library >> >> reg_prefix = 3*( ALPHA / DIGIT ) >> ; as assigned by the Library of Congress -- >> ; identifies a trusted third party >> ; to which the bracnh is delegated" > > Alfred Hoenes is better qualified than myself to respond to this. Yes, Tommi, you are right! This is an oversight in the -00 draft that needs to be corrected, to align the draft with RFC 3986 and the rfc2141bis draft. (Another possibility would of course be to introduce ALPHANUM as a 'local' ABNF rule in this draft.) If the BoF in Maastricht leads to WG formation (which I hope!), we would prefer to submit the next version directly as a WG draft and avoid the intermediate step (and work for editors and readers) of a second individual draft. So most likely the next draft version will be submitted shortly after the IETF meeting. >> >> --- >> >> I don't remember seeing the reasoning behind this prohibition in 4.6.: >> "Dividing non-ISO 3166-based namespaces further with sub-namespace codes >> MUST NOT be done." >> >> Would you care to enlighten me why this MUST NOT exists in the first place? > > Yes. > > When an ISO 3166 namespace is subdivided, then according to the RFC 3188 > the national library in question must maintain the registry of these > sub-namespaces. > > For non-ISO 3166 namespaces RFC 3188 states that there will be only one > list, maintained by the Library of Congress (to my knowledge no such > namespaces have been assigned yet, and it is not clear if there will be > a demand for them). We do not know what kind of organisations would > register these namespaces for themselves, and whether they would be > willing to take the responsibility of maintaining a registry of > sub-divisions of their namespace. For the sake of simplicity I thought > that it would be better to just ban sub-division of these namespaces. Simplicity is an important goal. Unless there are convincing arguments to the contrary, we should not spend cycles for rules and procedures for very far-fetched and unlikely future scenarios. In this case, the stability argument also counts very much. Experience in protocol work has shown that in such cases, actual need (if it arises at all), often does not precisely match what had been envisioned long before, and that has lead to artificial solutions neither matching the actual need nor being a good fit for what has been provided tentatively in advance. In this case, we would have to introduce mechanisms to guarantee the required properties and strong policies, and would not even have a single example of a non-cc sub-namespace so far that could provide guidance and indicate circumstances that might make further organizatorial subdivision necessary. This overhead (in specification and operations!) should not be undertaken too lightly. So it might actually be wise to stay with the previous restriction. If actual strong demand arises in (say) five years for some such delegations, a short update document introducing what actually is needed might be a much better choice. For now, in place of a single registered NBN sub-namespace with a couple of sub-sub-namespace registrations, a couple of NBN sub-namespace directly registered with the Library of Congress would be functionally equivalent. 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 | +------------------------+--------------------------------------------+ > Best regards, > > Juha >> >> --- >> >> Cheers, >> Tommi >> -- >> Tommi Jauhiainen (Mr.) >> >> Information Systems Specialist TietojÌrjestelmÌasiantuntija >> The National Library of Finland Kansalliskirjasto >> >> PL 26 (Teollisuuskatu 23) http://www.kansalliskirjasto.fi/ >> 00014 University of Helsinki Tel. +358 50 415 0 555 >> _______________________________________________ >> 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 > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From stpeter@stpeter.im Wed Jun 30 18:36:59 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 02A553A68D6 for ; Wed, 30 Jun 2010 18:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[AWL=0.153, 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 xyYuDC-ni5Dw for ; Wed, 30 Jun 2010 18:36:58 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 084593A68D3 for ; Wed, 30 Jun 2010 18:36:58 -0700 (PDT) Received: from squire.local (dsl-179-197.dynamic-dsl.frii.net [216.17.179.197]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BA34C40E4D for ; Wed, 30 Jun 2010 19:37:08 -0600 (MDT) Message-ID: <4C2BF143.501@stpeter.im> Date: Wed, 30 Jun 2010 19:37:07 -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: "urn@ietf.org" 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="------------ms030101040306090405080203" Subject: [urn] The Curious History of Uniform Resource Names 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, 01 Jul 2010 01:36:59 -0000 This is a cryptographically signed message in MIME format. --------------ms030101040306090405080203 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Leslie Daigle has written an interesting article in the latest IETF Journal about "The Curious History of Uniform Resource Names"... http://www.isoc.org/tools/blogs/ietfjournal/?p=3D1705 Check it out! Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms030101040306090405080203 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 hvcNAQkFMQ8XDTEwMDcwMTAxMzcwN1owIwYJKoZIhvcNAQkEMRYEFNRzOSbXNqV5snJd90P1 yDv5+PGvMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAY/wtR1anRp1FLwqNVrlNQwvThlHz7glrxvTgQRdk 2YXOS9mt99ETQFpdTSmSTqNWGAZlrseQI0j1RvcWJ6gk9RsoozkY06gywot3eFB+pgmxhj6H OSpnozTsQGGat+ZMo8SG40WWy3UBDsBPuA09DbnhjQg1DwCRiS6M875XBpk2qnGiL7GfU7bd Bq5l1TBHNBbs6uCHCjkemQJMf8aCAeecYlx+a1+adWNB3Fv7KQmEx+BL4ZjQJEXmeoh9sezO T+FU+oN/297gTlkSajq0WS9FcTIi3kfCvRkY3MVDpew2Xi5SmK8OLyi8tyYgnHGzFTkH0xTZ KQAxAWuUODe4VQAAAAAAAA== --------------ms030101040306090405080203--