From nobody Tue Dec 1 11:19:10 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 467431B2F50 for ; Tue, 1 Dec 2015 11:19:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRh6CNoOhsz5 for ; Tue, 1 Dec 2015 11:19:02 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E85C61B2F42 for ; Tue, 1 Dec 2015 11:19:00 -0800 (PST) Received: from [100.110.240.124] (unknown [104.135.0.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 800C3509BD; Tue, 1 Dec 2015 14:18:57 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_5C0C83A2-D1CB-4F52-B289-C0E4E1E3748A"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Leonard In-Reply-To: <565C7688.9020008@gmx.de> Date: Tue, 1 Dec 2015 11:18:10 -0800 Message-Id: <474268EC-F30A-42E7-B08C-CF731A27604C@seantek.com> References: <5657436C.6010305@seantek.com> <565A79C5.3070405@it.aoyama.ac.jp> <1E05E4F31732434D1C78736B@JcK-HP5.jck.com> <565B74FC.6070400@andyet.net> <34744C7E83150D15D4405C1A@JcK-HP5.jck.com> <565BF649.80507@seantek.com> <565BFA93.10707@it.aoyama.ac.jp> <565C0300.3040005@seantek.com> <565C0C49.8060109@gmx.de> <565C70B7.5000709@seantek.com> <565C7688.9020008@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: urn@ietf.org Subject: Re: [urn] UTF-8 ABNF Re: What Happened to UTF-8? X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 19:19:09 -0000 --Apple-Mail=_5C0C83A2-D1CB-4F52-B289-C0E4E1E3748A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 30, 2015, at 8:17 AM, Julian Reschke = wrote: > On 2015-11-30 16:52, Sean Leonard wrote: >> ... >>> -1. The ABNF is the wrong place to enforce constraints like these. >>=20 >> Explain? "Wrong" is not a technical argument. >>=20 >> The ABNF is not "enforcing constraints"; the standards document is = (or >> will). The ABNF accurately reflects the standard. >> ... >=20 > But the *purpose* (IMHO) of the ABNF is not solely to "reflect the = standard" but to also to assist people in writing conforming parsers. >=20 > Do you expect *parsers* to reject invalid UTF-8 sequences? I don't; = I'd rather expect the consumer of the parser to inspect the octet = sequences (that's why a UTF-8 decoder does, no?) >=20 > So, phrased differently, you're mixing multiple layers in the ABNF, = which I believe wouldn't be helpful. Actually after thinking about it, I respectfully but completely = disagree. [The remainder of this e-mail message assumes that there is = consensus about the assigned-name portion of a urn: URI being UTF-8, = which is the status quo from RFC 2141. There seems to be a sub-thread = with dissension in the ranks on this topic.] The ABNF is supposed to define the behavior of conforming = implementations: both parsers *and* generators. A generator that = generates arbitrary "%" HEXDIG HEXDIG is non-conforming, plain and = simple. Let=92s look at other IETF standards. Consider that UTF-8 itself (in the = IETF) is standardized by RFC 3629. The ABNF of Section 4 of that RFC = (quoted below) is normatively referenced by EAI [RFC6531] [RFC6532] = (direct reference) and by LDAP [RFC4510] et. seq. including [RFC4512] = (indirect reference). I am sure there are others. Therefore, a = conforming LDAP system or EAI system MUST reject ill-formed UTF-8 = sequences. Important features are that (well-formed) UTF-8 has no way to = express different octet sequences for the same code point (overlong = encoding hacks like C0 80 don=92t work); furthermore, it can only = express Unicode scalar values, *not* the surrogate Unicode code points = U+D800-U+DFFF (in contrast to so-called Wobbly Transformation Format = WTF-8, ). This means, among = other things, that systems that do not check for unpaired surrogates = (e.g., Windows filenames), cannot have their literal Unicode data shoved = into those protocol slots. Whether this is a Good Thing or a Bad Thing, = it=92s a Thing and it needs to be acknowledged. Do I expect parsers to reject invalid UTF-8 sequences? YES. It doesn=92t = matter if the parser is some hand-rolled thing or code automatically = generated from ABNF or anything else. =93Ill-formed=94 UTF-8 sequences = are harmful for security and interoperability; there is plenty of = written evidence on this point. As a case in point: there is no reason why =93%FF=94 or similar should = ever appear in a (UTF-8) assigned-name. The octet FF never appears in = UTF-8--it is out-of-band. I have a great deal of skepticism that =93the consumer of the parser = [will] inspect the octet sequences=94. As the Wikipedia article states: = =93Many systems that deal with UTF-8 work [the WTF-8] way without = considering it a different encoding, as it is simpler.=94 Garbage-in, = garbage-out. A consumer of the parsed output will likely only check for = invalid UTF-8 subsequences if it is converting between UTF-8 and some = other encoding, namely UTF-16 or UTF-32. Doing it =93in the ABNF=94 is = actually more efficient, because only one pass is needed to confirm = validity. Requiring a system to parse the % values, and then re-parse, = is not only double the work but something that most = lazy/unaware/efficient implementers are unlikely to do. Others have called for =93pressure for 3986bis=94 [presumably, to = promote UTF-8]. The proposed ABNF for percent-encoded UTF-8 may look = complicated...but UTF-8 is just as =93complicated=94 and you can = abstract that out by referring to =93utf8-pct-encoded=94 and ignoring = the implementation details (as, presumably, the EAI standards did). Consider how much easier the whole character encoding thing would have = been, if URIs were always Unicode-oriented, rather than octet-oriented. = We would have an unambiguous %-syntax akin to entity references like = =93B%FC%cher=94 for =93B=FCcher=94, and transitioning between URIs and = IRIs would be much more seamless. Instead, we have a weird situation = where that word could be maybe =93B%FCcher=94, maybe =93B%C3%BCcher=94, = maybe =93B%81cher=94, or maybe even =93xn--bcher-kva=94 depending on the = position in the URI and the assumed character encoding in the = environment. Not only URN parts, but any URI part for other URI schemes *should* use = utf8-pct-encoded when they want UTF-8 percent-encoded. Best regards, Sean *** UTF8-octets =3D *( UTF8-char ) UTF8-char =3D UTF8-1 / UTF8-2 / UTF8-3 / UTF8-4 UTF8-1 =3D %x00-7F UTF8-2 =3D %xC2-DF UTF8-tail UTF8-3 =3D %xE0 %xA0-BF UTF8-tail / %xE1-EC 2( UTF8-tail ) / %xED %x80-9F UTF8-tail / %xEE-EF 2( UTF8-tail ) UTF8-4 =3D %xF0 %x90-BF 2( UTF8-tail ) / %xF1-F3 3( UTF8-tail ) = / %xF4 %x80-8F 2( UTF8-tail ) UTF8-tail =3D %x80-BF *** >=20 > Best regards, Julian --Apple-Mail=_5C0C83A2-D1CB-4F52-B289-C0E4E1E3748A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9jCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBT8wggQnoAMCAQICEBpCSs8n+cQbczyWKtueyecwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTAyMDIwMDAwMDBaFw0xNjAy MDIyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFGRlditpZXRmQHNlYW50ZWsuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz4n20qAOzUtC1oNz5zgTny0JRBE1mJZszV2s6EurahKP vku7E+utnLhcaNahAWr2oZgeCK9uhEqijaC4qLZHnGt/+lnbsQtjmMJrcFCzhDZjDOJdYzmuS2cU vZqY7YwzCG6jSfs4gwNh+29MS6faY6ucncbnfO9rBB0xu5GIdI3BzsPNYnACNlBYU7w4X4GA0/Mw NAabNhDgxU2Tw1fl5w1Vt+6xRTXBk6V93LyVZN9wBIOpr2MuhoCJLHZrLirv/mbQE5ao4pkJLR/s yYhS1Ko4MSiJmR3ugKPkxEo6DZkuJrfck36hLmtMo3yuzi7hkXmDzPKkdLlNj+Xek1GWtwIDAQAB o4IB8jCCAe4wHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFBpm5d7y 8PBT6NqnIVbfNK8hbpPGMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcG CCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7Bgwr BgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMw XQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMwgYAw WAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRkZXYraWV0ZkBzZWFudGVrLmNvbTANBgkqhkiG9w0B AQsFAAOCAQEAeIf/Nevvv10ssk0unrJb9FC8lJi41sSpq5AFYtmC8IXwUmNxL7L5uE3tGlNJVoTK ZvGeklYWDRCzq6zqte221TowXYmFO7G27rJZbQRjLzQoY63rMlFPFrjqQCEA6rDgo9DlFO9/81P7 ZC7xvZ52WH7e3p/yJNA4Av8E0eeavhC+l+cwtrw0wCp3gUs5xJT0koGVvli2wR18zecG3ib3ml+G nDDv2AH7OhcyhVoj6V9AeGQa2HqaVpOQVRUNPamqr3xeARKk5sUSeBvxlF+0FWhl+AnhqNdxmeEp qpgSvbcS1jbTsqApvgsBcDzjC09wV8mtBoMCtqlHvF3YY2z55jGCA8MwggO/AgEBMIGwMIGbMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtueyecw CQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTUxMjAxMTkxODUwWjAjBgkqhkiG9w0BCQQxFgQU1K6f9vehrRviCL7DN6vupsGRW7QwgcEGCSsG AQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhAaQkrPJ/nEG3M8lirbnsnnMIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqGSIb3DQEB AQUABIIBACqW7qnLAtOOO458nMvYXiEB+lrjObnUgxxEw2Jznk6UP90l5dLKegGKS4CtE8340jC2 BtHk3fCd3wC8nUACaZSTvXl7JuRehvjk/SDNtp55ZB4HPg9MeoxLeW4ijNmuxQ15m8WhjbFw70ag eP4rsgXe0cpVupfaA4M2nsYXjFXzJnrXaX29beDv0WPJHO5GQ+lUnkLdkuaoCjBY+LWCwDJESZ+H qCMPfApvvxzHfBbY/rm+IiwadbLK3J5qMl97L59wpCv0+nEsdFCURjpNsvHVEHv2yPugOZh+uj/A 69PoiVDZeDENg5Fh4NEbLcxWn0EWJyTlXdLaHMJe+ZBZUN4AAAAAAAA= --Apple-Mail=_5C0C83A2-D1CB-4F52-B289-C0E4E1E3748A-- From nobody Tue Dec 1 16:34:36 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF4401B2EDC for ; Tue, 1 Dec 2015 16:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxuOSCTETPQA for ; Tue, 1 Dec 2015 16:34:31 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD73B1AC3B3 for ; Tue, 1 Dec 2015 16:34:31 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 29617206BA for ; Tue, 1 Dec 2015 19:34:31 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Tue, 01 Dec 2015 19:34:31 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=t0075k95/sr0gI+nNiUBzgdINAg=; b=mchJy Jy2WsYeEtQfg1KGstu8sJgwmXzs15cyk1YtnPMG7uZMlAqIv+GufYjCaU3uofxtK kiXgApTt2vpdgVlr+2Le1jIIPPcMKMde7fRS2vB64Hc+7t3igwrnsxDtsGpe8ngs o7pfwrcY+yG7ItJXTx14qVJWcGlgHUrfBEG2Sk= X-Sasl-enc: dVw19HtaqzyKJ2zoQ8+n8IzcdEm5GS8BZHOPXCVKDgCL 1449016470 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id BAB7DC016F0; Tue, 1 Dec 2015 19:34:30 -0500 (EST) To: urn@ietf.org References: <5657436C.6010305@seantek.com> <565A79C5.3070405@it.aoyama.ac.jp> <1E05E4F31732434D1C78736B@JcK-HP5.jck.com> <565B74FC.6070400@andyet.net> <34744C7E83150D15D4405C1A@JcK-HP5.jck.com> <565BF649.80507@seantek.com> <565BFA93.10707@it.aoyama.ac.jp> <565C0300.3040005@seantek.com> <565C0C49.8060109@gmx.de> <565C70B7.5000709@seantek.com> <565C7688.9020008@gmx.de> <474268EC-F30A-42E7-B08C-CF731A27604C@seantek.com> From: Keith Moore Message-ID: <565E3C84.6090602@network-heretics.com> Date: Tue, 1 Dec 2015 19:34:12 -0500 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <474268EC-F30A-42E7-B08C-CF731A27604C@seantek.com> Content-Type: multipart/alternative; boundary="------------080808040308030805040204" Archived-At: Subject: Re: [urn] UTF-8 ABNF Re: What Happened to UTF-8? X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 00:34:34 -0000 This is a multi-part message in MIME format. --------------080808040308030805040204 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 12/01/2015 02:18 PM, Sean Leonard wrote: > The ABNF is supposed to define the behavior of conforming implementations: both parsers*and* generators. A generator that generates arbitrary "%" HEXDIG HEXDIG is non-conforming, plain and simple. Nevertheless, you don't want the parser to invalidate existing URNs. Also, it's not absolutely necessary that the grammar recognize exactly the set of syntactically valid URNs. It is sufficient if the grammar recognizes all valid URNs but there are some strings that are valid under the grammar but invalid for other reasons. For instance, a URN isn't valid unless its namespace ID is registered, but we don't expect the grammar to recognize that. Similarly for most namespaces a URN isn't valid if its NSS hasn't been issued by the namespace, but we don't expect the grammar to recognize that either. Actually I would suggest that rather than trying to impose a strict rule that expects all URNs to conform to UTF-8, and implicitly expects clients to do checking on URNs for UTF-8 validity, that instead it should be up to the namespace to enforce this rule at assignment time. Nobody else should care whether the NSS is UTF-8 or not. The NSS should be considered opaque by everybody but the namespace anyway. Finally, it's generally been my experience that overly strict parsers break interoperability. If some namespace accidentally issues a NSS that doesn't conform to UTF-8, it does more harm than good for client implementations to refuse to resolve it. Keith --------------080808040308030805040204 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 12/01/2015 02:18 PM, Sean Leonard wrote:
The ABNF is supposed to define the behavior of conforming implementations: both parsers *and* generators. A generator that generates arbitrary "%" HEXDIG HEXDIG is non-conforming, plain and simple.
Nevertheless, you don't want the parser to invalidate existing URNs.  

Also, it's not absolutely necessary that the grammar recognize exactly the set of syntactically valid URNs.   It is sufficient if the grammar recognizes all valid URNs but there are some strings that are valid under the grammar but invalid for other reasons.   For instance, a URN isn't valid unless its namespace ID is registered, but we don't expect the grammar to recognize that.   Similarly for most namespaces a URN isn't valid if its NSS hasn't been issued by the namespace, but we don't expect the grammar to recognize that either.

Actually I would suggest that rather than trying to impose a strict rule that expects all URNs to conform to UTF-8, and implicitly expects clients to do checking on URNs for UTF-8 validity, that instead it should be up to the namespace to enforce this rule at assignment time.   Nobody else should care whether the NSS is UTF-8 or not.   The NSS should be considered opaque by everybody but the namespace anyway.

Finally, it's generally been my experience that overly strict parsers break interoperability.   If some namespace accidentally issues a NSS that doesn't conform to UTF-8, it does more harm than good for client implementations to refuse to resolve it.

Keith

--------------080808040308030805040204-- From nobody Wed Dec 2 12:09:07 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D81F61B2C7F for ; Wed, 2 Dec 2015 12:08:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDbTbBp70Dqm for ; Wed, 2 Dec 2015 12:08:54 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47CEC1B2C6D for ; Wed, 2 Dec 2015 12:08:54 -0800 (PST) Received: from [100.110.240.124] (unknown [104.135.0.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4D7D8509BB; Wed, 2 Dec 2015 15:08:51 -0500 (EST) From: Sean Leonard Content-Type: multipart/signed; boundary="Apple-Mail=_39D60FE5-4695-43C6-8F2F-34A90054DB9D"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Wed, 2 Dec 2015 12:08:21 -0800 References: <5657436C.6010305@seantek.com> <565A79C5.3070405@it.aoyama.ac.jp> <1E05E4F31732434D1C78736B@JcK-HP5.jck.com> <565B74FC.6070400@andyet.net> <34744C7E83150D15D4405C1A@JcK-HP5.jck.com> <565BF649.80507@seantek.com> <565BFA93.10707@it.aoyama.ac.jp> <565C0300.3040005@seantek.com> <565C0C49.8060109@gmx.de> <565C70B7.5000709@seantek.com> <565C7688.9020008@gmx.de> <474268EC-F30A-42E7-B08C-CF731A27604C@seantek.com> <565E3C84.6090602@network-heretics.com> To: Keith Moore , urn@ietf.org In-Reply-To: <565E3C84.6090602@network-heretics.com> X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [urn] UTF-8 ABNF Re: What Happened to UTF-8? X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 20:08:59 -0000 --Apple-Mail=_39D60FE5-4695-43C6-8F2F-34A90054DB9D Content-Type: multipart/alternative; boundary="Apple-Mail=_10397397-21A0-46E0-9FE5-2859ADB0D16A" --Apple-Mail=_10397397-21A0-46E0-9FE5-2859ADB0D16A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Dec 1, 2015, at 4:34 PM, Keith Moore = wrote: > On 12/01/2015 02:18 PM, Sean Leonard wrote: >> The ABNF is supposed to define the behavior of conforming = implementations: both parsers *and* generators. A generator that = generates arbitrary "%" HEXDIG HEXDIG is non-conforming, plain and = simple. > Nevertheless, you don't want the parser to invalidate existing URNs. =20= Correct. And such a UTF-8-enabled ABNF parser won=92t invalidate = existing URNs, because RFC 2141 says they are all UTF-8 percent-encoded. = I don=92t see any other way to interpret Section 2.2 of RFC 2141. In the following conversation, I (going to) assume that by =93URN=94 you = mean the assigned-name production, which is NID and NSS. NID is = ASCII-only. So really we=92re just talking about NSS. As has been = pointed out, r-components, q-components, and f-components have different = encoding issues, respectively. >=20 > Also, it's not absolutely necessary that the grammar recognize exactly = the set of syntactically valid URNs. It is sufficient if the grammar = recognizes all valid URNs but there are some strings that are valid = under the grammar but invalid for other reasons. For instance, a URN = isn't valid unless its namespace ID is registered, but we don't expect = the grammar to recognize that. Similarly for most namespaces a URN = isn't valid if its NSS hasn't been issued by the namespace, but we don't = expect the grammar to recognize that either. The other reasons you mentioned are not computable. ABNF is a context-free grammar that can be interpreted (implemented by) = a pushdown automaton. Specific NIDs and their NSS constraints are not = specified in the URN grammar because they are open-ended and not known; = no machine can compute such a thing. The argument is a red herring. UTF-8 is known. Its constraints are computable by a pushdown automaton. = (Actually it=92s computable by a finite-state automaton, which is the = =93best=94 kind, because it can be implemented in the widest variety of = resource-constrainted hardware.) Furthermore, it is a self-synchronizing = code. Many character encodings=97including the arcane Unicode ones that = predate UTF-8=97do not have these properties. By this logic, I would say that not only is UTF-8 a =93Good Idea=94, = UTF-8 is =93Necessary=94 for URN interoperability. Otherwise people = don=92t know what characters map to what (percent-encoded) productions, = making comparisons essentially impossible (i.e., uncomputable). >=20 > Actually I would suggest that rather than trying to impose a strict = rule that expects all URNs to conform to UTF-8, and implicitly expects = clients to do checking on URNs for UTF-8 validity, that instead it = should be up to the namespace to enforce this rule at assignment time. = Nobody else should care whether the NSS is UTF-8 or not. The NSS = should be considered opaque by everybody but the namespace anyway. >=20 > Finally, it's generally been my experience that overly strict parsers = break interoperability. If some namespace accidentally issues a NSS = that doesn't conform to UTF-8, it does more harm than good for client = implementations to refuse to resolve it. If an NSS is not UTF-8 encoded, it is not conforming with RFC 2141. = Again, I call red herring. Sean --Apple-Mail=_10397397-21A0-46E0-9FE5-2859ADB0D16A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Dec 1, 2015, at 4:34 PM, Keith = Moore <moore@network-heretics.com&= gt; wrote:

=20 =20
On 12/01/2015 02:18 PM, Sean Leonard wrote:
The ABNF is supposed to define the behavior of =
conforming implementations: both parsers *and* =
generators. A generator that generates arbitrary "%" HEXDIG HEXDIG is =
non-conforming, plain and simple.
Nevertheless, you don't want the parser to invalidate existing URNs.   =

Correct. And such a = UTF-8-enabled ABNF parser won=92t invalidate existing URNs, because RFC = 2141 says they are all UTF-8 percent-encoded. I don=92t see any other = way to interpret Section 2.2 of RFC 2141.

In = the following conversation, I (going to) assume that by =93URN=94 you = mean the assigned-name production, which is NID and NSS. NID is = ASCII-only. So really we=92re just talking about NSS. As has been = pointed out, r-components, q-components, and f-components have different = encoding issues, respectively.


Also, it's not absolutely necessary that the grammar recognize exactly the set of syntactically valid URNs.   It is = sufficient if the grammar recognizes all valid URNs but there are some strings that are valid under the grammar but invalid for other = reasons.   For instance, a URN isn't valid unless its namespace ID is registered, but we don't expect the grammar to recognize = that.   Similarly for most namespaces a URN isn't valid if its NSS hasn't been issued by the namespace, but we don't expect the grammar to recognize that either.

The = other reasons you mentioned are not = computable.

ABNF is a context-free grammar that = can be interpreted (implemented by) a pushdown automaton. Specific NIDs = and their NSS constraints are not specified in the URN grammar because = they are open-ended and not known; no machine can compute such a thing. = The argument is a red herring.

UTF-8 is known. = Its constraints are computable by a pushdown automaton. (Actually it=92s = computable by a finite-state automaton, which is the =93best=94 kind, = because it can be implemented in the widest variety of = resource-constrainted hardware.) Furthermore, it is a self-synchronizing = code. Many character encodings=97including the arcane Unicode ones that = predate UTF-8=97do not have these = properties.

By this logic, I would say that not = only is UTF-8 a =93Good Idea=94, UTF-8 is =93Necessary=94 for URN = interoperability. Otherwise people don=92t know what characters map to = what (percent-encoded) productions, making comparisons essentially = impossible (i.e., uncomputable).


Actually I would suggest that rather than trying to impose a strict rule that expects all URNs to conform to UTF-8, and implicitly expects clients to do checking on URNs for UTF-8 validity, that instead it should be up to the namespace to enforce this rule at assignment time.   Nobody else should care whether the NSS is = UTF-8 or not.   The NSS should be considered opaque by everybody but = the namespace anyway.

Finally, it's generally been my experience that overly strict parsers break interoperability.   If some namespace = accidentally issues a NSS that doesn't conform to UTF-8, it does more harm than good for client implementations to refuse to resolve = it.

If an NSS is not UTF-8 = encoded, it is not conforming with RFC 2141. Again, I call red = herring.

Sean

= --Apple-Mail=_10397397-21A0-46E0-9FE5-2859ADB0D16A-- --Apple-Mail=_39D60FE5-4695-43C6-8F2F-34A90054DB9D Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9jCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBT8wggQnoAMCAQICEBpCSs8n+cQbczyWKtueyecwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTAyMDIwMDAwMDBaFw0xNjAy MDIyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFGRlditpZXRmQHNlYW50ZWsuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz4n20qAOzUtC1oNz5zgTny0JRBE1mJZszV2s6EurahKP vku7E+utnLhcaNahAWr2oZgeCK9uhEqijaC4qLZHnGt/+lnbsQtjmMJrcFCzhDZjDOJdYzmuS2cU vZqY7YwzCG6jSfs4gwNh+29MS6faY6ucncbnfO9rBB0xu5GIdI3BzsPNYnACNlBYU7w4X4GA0/Mw NAabNhDgxU2Tw1fl5w1Vt+6xRTXBk6V93LyVZN9wBIOpr2MuhoCJLHZrLirv/mbQE5ao4pkJLR/s yYhS1Ko4MSiJmR3ugKPkxEo6DZkuJrfck36hLmtMo3yuzi7hkXmDzPKkdLlNj+Xek1GWtwIDAQAB o4IB8jCCAe4wHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFBpm5d7y 8PBT6NqnIVbfNK8hbpPGMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcG CCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7Bgwr BgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMw XQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMwgYAw WAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRkZXYraWV0ZkBzZWFudGVrLmNvbTANBgkqhkiG9w0B AQsFAAOCAQEAeIf/Nevvv10ssk0unrJb9FC8lJi41sSpq5AFYtmC8IXwUmNxL7L5uE3tGlNJVoTK ZvGeklYWDRCzq6zqte221TowXYmFO7G27rJZbQRjLzQoY63rMlFPFrjqQCEA6rDgo9DlFO9/81P7 ZC7xvZ52WH7e3p/yJNA4Av8E0eeavhC+l+cwtrw0wCp3gUs5xJT0koGVvli2wR18zecG3ib3ml+G nDDv2AH7OhcyhVoj6V9AeGQa2HqaVpOQVRUNPamqr3xeARKk5sUSeBvxlF+0FWhl+AnhqNdxmeEp qpgSvbcS1jbTsqApvgsBcDzjC09wV8mtBoMCtqlHvF3YY2z55jGCA8MwggO/AgEBMIGwMIGbMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtueyecw CQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTUxMjAyMjAwODQ3WjAjBgkqhkiG9w0BCQQxFgQU6+iMnPqzvLGgulYyaTle3bhOjgcwgcEGCSsG AQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhAaQkrPJ/nEG3M8lirbnsnnMIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqGSIb3DQEB AQUABIIBAFVlNrmEaUq6xCWuQaewZyf9yGJtnwWnur9b+kIGjBJ80DpkgPRcTd2esy0WgrUV415Y AmVp3K3ohp24XVhNYtJA2mLND90E9d2j0RqtQoLYswC/8jZSMmdkWABzbX08mOAXGukxI7TN09Hn Quh3u8qltGRAIjua37zQncbmF+maagzrDlUF58Rk5Xl9u5dxgtTpRHz3t1ssLAejsrcVq5PLRnoY M3o2fuOyuPQABI8y7gTeD/MAOTbx1lbvReyVUzcCYE6UUZPUrimrz3e49O6i9ynDtIQk+nWo366q lip/wr3ebNvYM2FhSRI5r1R4tJapdig8WKfXzDL3Rz+IojcAAAAAAAA= --Apple-Mail=_39D60FE5-4695-43C6-8F2F-34A90054DB9D-- From nobody Wed Dec 2 14:14:50 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB3DF1A038D for ; Wed, 2 Dec 2015 14:14:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_I_LETTER=-2, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBqtu25RgnAD for ; Wed, 2 Dec 2015 14:14:47 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 597CD1A034F for ; Wed, 2 Dec 2015 14:14:47 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 948AB20875 for ; Wed, 2 Dec 2015 17:14:46 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Wed, 02 Dec 2015 17:14:46 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=mkArLw6ie9KX5WP 2hbh+vQhBITU=; b=ZU3IRd/J8lvyr4JHM6cN8Pj80O6Z9zpX4iXWnk+by2NhQgN I8sIX0wb6iYreEyjbAahfvwH9WxR1N0CIkmnYAOeNK+r63V8JxJR41ujDJucVn3j TTZ87Bv/qF7FiTZLJ49BE7lOmpiA4SH8zVl5/xb2ddaFZiYASrepbMGpFFUs= X-Sasl-enc: djW/Y2CQ8eljdbThzqMUICPKULqa4EmQ/Hc72OjqYALv 1449094485 Received: from [21.148.211.13] (unknown [66.87.153.13]) by mail.messagingengine.com (Postfix) with ESMTPA id B6F37C016DB; Wed, 2 Dec 2015 17:14:45 -0500 (EST) References: <5657436C.6010305@seantek.com> <565A79C5.3070405@it.aoyama.ac.jp> <1E05E4F31732434D1C78736B@JcK-HP5.jck.com> <565B74FC.6070400@andyet.net> <34744C7E83150D15D4405C1A@JcK-HP5.jck.com> <565BF649.80507@seantek.com> <565BFA93.10707@it.aoyama.ac.jp> <565C0300.3040005@seantek.com> <565C0C49.8060109@gmx.de> <565C70B7.5000709@seantek.com> <565C7688.9020008@gmx.de> <474268EC-F30A-42E7-B08C-CF731A27604C@seantek.com> <565E3C84.6090602@network-heretics.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-48681D1D-5F27-4F41-8B76-63334397BB7E Message-Id: X-Mailer: iPhone Mail (12F70) From: Keith Moore Date: Wed, 2 Dec 2015 17:14:42 -0500 To: Sean Leonard Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] UTF-8 ABNF Re: What Happened to UTF-8? X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 22:14:50 -0000 --Apple-Mail-48681D1D-5F27-4F41-8B76-63334397BB7E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sent from my iPhone > On Dec 2, 2015, at 3:08 PM, Sean Leonard wrote: >=20 >=20 >> On Dec 1, 2015, at 4:34 PM, Keith Moore wrot= e: >>=20 >>> On 12/01/2015 02:18 PM, Sean Leonard wrote: >>> The ABNF is supposed to define the behavior of conforming implementation= s: both parsers *and* generators. A generator that generates arbitrary "%" H= EXDIG HEXDIG is non-conforming, plain and simple. >> Nevertheless, you don't want the parser to invalidate existing URNs. =20 >=20 > Correct. And such a UTF-8-enabled ABNF parser won=E2=80=99t invalidate exi= sting URNs, because RFC 2141 says they are all UTF-8 percent-encoded. I don=E2= =80=99t see any other way to interpret Section 2.2 of RFC 2141. There were URNs in use before RFC 2141. And it's a bad idea to assume that a= ll URNs even after RFC 2141 was published adhered to the letter of the spec,= particularly when the 2141 grammar wasn't that strict. >=20 > In the following conversation, I (going to) assume that by =E2=80=9CURN=E2= =80=9D you mean the assigned-name production, which is NID and NSS. NID is A= SCII-only. So really we=E2=80=99re just talking about NSS. As has been point= ed out, r-components, q-components, and f-components have different encoding= issues, respectively. Fair enough. We should not presume anything about the character encoding of= either q- or f- components because those are not within our control. >>=20 >> Also, it's not absolutely necessary that the grammar recognize exactly th= e set of syntactically valid URNs. It is sufficient if the grammar recogni= zes all valid URNs but there are some strings that are valid under the gramm= ar but invalid for other reasons. For instance, a URN isn't valid unless i= ts namespace ID is registered, but we don't expect the grammar to recognize t= hat. Similarly for most namespaces a URN isn't valid if its NSS hasn't bee= n issued by the namespace, but we don't expect the grammar to recognize that= either. >=20 > The other reasons you mentioned are not computable. True, but just because something can be recognized by an FSM doesn't mean we= have to make the grammar strictly recognize it. >=20 > By this logic, I would say that not only is UTF-8 a =E2=80=9CGood Idea=E2=80= =9D, UTF-8 is =E2=80=9CNecessary=E2=80=9D for URN interoperability. > Otherwise people don=E2=80=99t know what characters map to what (percent-e= ncoded) productions, making comparisons essentially impossible (i.e., uncomp= utable). UTF-8 does not solve this problem because there is no single way of translat= ing other character encoding schemes to Unicode. To the extent existing nam= espaces are using UTF-8 to encode non-ascii characters in legacy names, they= 've presumably chosen their translation algorithms independently of one anot= her. And furthermore this is Not Our Problem, because it only comes into play whe= n translating legacy named to URNs and vice versa. That's inherently up to e= ach namespace to define. Nobody should be trying to decode or display the d= ecoded versions of percent-encodings within an NSS unless they have namespac= e-specific knowledge and are trying to translate back to legacy format. A U= RN is NOT some encoding of an arbitrary human-readable string; it is an opaq= ue token. >=20 >>=20 >> Actually I would suggest that rather than trying to impose a strict rule t= hat expects all URNs to conform to UTF-8, and implicitly expects clients to d= o checking on URNs for UTF-8 validity, that instead it should be up to the n= amespace to enforce this rule at assignment time. Nobody else should care w= hether the NSS is UTF-8 or not. The NSS should be considered opaque by eve= rybody but the namespace anyway. >>=20 >> Finally, it's generally been my experience that overly strict parsers bre= ak interoperability. If some namespace accidentally issues a NSS that does= n't conform to UTF-8, it does more harm than good for client implementations= to refuse to resolve it. >=20 > If an NSS is not UTF-8 encoded, it is not conforming with RFC 2141. It doesn't matter, and that's not a good excuse for breaking non confirming U= RNs that might exist. Keith= --Apple-Mail-48681D1D-5F27-4F41-8B76-63334397BB7E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


Sent from my iPhone
=
On Dec 2, 2015, at 3:08 PM, Sean Leonard <dev+ietf@seantek.com> wrote:





In the following conversation, I (going to) assume that by =E2= =80=9CURN=E2=80=9D you mean the assigned-name production, which is NID and N= SS. NID is ASCII-only. So really we=E2=80=99re just talking about NSS. As ha= s been pointed out, r-components, q-components, and f-components have differ= ent encoding issues, respectively.

Fair enough.  We should not presume anything about the character en= coding of either q- or f- components because those are not within our contro= l.


Also, it's not absolutely necessary that the grammar recognize exactly the set of syntactically valid URNs.   It is sufficien= t if the grammar recognizes all valid URNs but there are some strings that are valid under the grammar but invalid for other reasons. &nb= sp; For instance, a URN isn't valid unless its namespace ID is registered, but we don't expect the grammar to recognize that. &nbs= p; Similarly for most namespaces a URN isn't valid if its NSS hasn't been issued by the namespace, but we don't expect the grammar to recognize that either.

The oth= er reasons you mentioned are not computable.
<= div>
True, but just because something can be recognized by an FSM d= oesn't mean we have to make the grammar strictly recognize it.


By this logic, I would say that not= only is UTF-8 a =E2=80=9CGood Idea=E2=80=9D, UTF-8 is =E2=80=9CNecessary=E2= =80=9D for URN interoperability.
Otherwise people don=E2=80=99t know what characters map to w= hat (percent-encoded) productions, making comparisons essentially impossible= (i.e., uncomputable).

UTF-8 do= es not solve this problem because there is no single way of translating othe= r character encoding schemes to Unicode.  To the extent existing namesp= aces are using UTF-8 to encode non-ascii characters in legacy names, they've= presumably chosen their translation algorithms independently of one another= .

And furthermore this is Not Our Problem, because i= t only comes into play when translating legacy named to URNs and vice versa.=  That's inherently up to each namespace to define.  Nobody should= be trying to decode or display the decoded versions of percent-encodings wi= thin an NSS unless they have namespace-specific knowledge and are trying to t= ranslate back to legacy format.  A URN is NOT some encoding of an arbit= rary human-readable string; it is an opaque token.



Actually I would suggest that rather than trying to impose a strict rule that expects all URNs to conform to UTF-8, and implicitly expects clients to do checking on URNs for UTF-8 validity, that instead it should be up to the namespace to enforce this rule at assignment time.   Nobody else should care whether the NSS is UTF-8= or not.   The NSS should be considered opaque by everybody but the namespace anyway.

Finally, it's generally been my experience that overly strict parsers break interoperability.   If some namespace accidental= ly issues a NSS that doesn't conform to UTF-8, it does more harm than good for client implementations to refuse to resolve it.

If an NSS is not UTF-8 encoded, it is not conform= ing with RFC 2141.

It does= n't matter, and that's not a good excuse for breaking non confirming URNs th= at might exist.

Keith
= --Apple-Mail-48681D1D-5F27-4F41-8B76-63334397BB7E-- From nobody Wed Dec 2 14:42:31 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 568311A039D for ; Wed, 2 Dec 2015 14:42:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WD5n9l-P_LE for ; Wed, 2 Dec 2015 14:42:28 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE5701A039E for ; Wed, 2 Dec 2015 14:42:27 -0800 (PST) Received: from [100.110.240.124] (unknown [104.135.0.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E3FF4509BE; Wed, 2 Dec 2015 17:42:25 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_84D0CA22-5E46-43D5-9E4D-9C68D59A5A08"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Leonard In-Reply-To: Date: Wed, 2 Dec 2015 14:41:47 -0800 Message-Id: <275AA9AA-CD3B-409E-80B3-F591ED929231@seantek.com> References: <5657436C.6010305@seantek.com> <565A79C5.3070405@it.aoyama.ac.jp> <1E05E4F31732434D1C78736B@JcK-HP5.jck.com> <565B74FC.6070400@andyet.net> <34744C7E83150D15D4405C1A@JcK-HP5.jck.com> <565BF649.80507@seantek.com> <565BFA93.10707@it.aoyama.ac.jp> <565C0300.3040005@seantek.com> <565C0C49.8060109@gmx.de> <565C70B7.5000709@seantek.com> <565C7688.9020008@gmx.de> <474268EC-F30A-42E7-B08C-CF731A27604C@seantek.com> <565E3C84.6090602@network-heretics.com> To: Keith Moore X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] UTF-8 ABNF Re: What Happened to UTF-8? X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 22:42:30 -0000 --Apple-Mail=_84D0CA22-5E46-43D5-9E4D-9C68D59A5A08 Content-Type: multipart/alternative; boundary="Apple-Mail=_8A606806-C735-4AE4-9BE8-D02823EE469F" --Apple-Mail=_8A606806-C735-4AE4-9BE8-D02823EE469F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Dec 2, 2015, at 2:14 PM, Keith Moore = wrote: >=20 >=20 > Sent from my iPhone >=20 > On Dec 2, 2015, at 3:08 PM, Sean Leonard wrote: >=20 >>=20 >>=20 >> If an NSS is not UTF-8 encoded, it is not conforming with RFC 2141. >=20 > It doesn't matter, and that's not a good excuse for breaking non = confirming URNs that might exist. Remind me: what is the point of writing a standard that bends over = backwards for non conforming URNs, when they never conformed in the = first place? It just seems that this WG or the chairs need to decide if the NSS is = UTF-8 encoded or not. Or if it=92s some convoluted = well-things-not-in-pchar-are-something-else-but-we-cannot-agree-on-anythin= g-so-we-will-make-the-world-more-convoluted-instead-of-actually-something-= that-works-like-UTF-8. The text of RFC 2141 Section 2.2 has a counterpart in urnbis Section = 3.2, but the actual text is markedly different. The RFC 2141 text has = already been quoted. Here is proposed text for urnbis, in bold. Note that there are only two = small changes. *** 3.2. Namespace Specific String The namespace specific string (NSS) is a unique identifier that is assigned and managed in a consistent way and that conforms to the definition of the relevant namespace. The combination of the NID (unique across the entire "urn" scheme) and the NSS (unique within the namespace) ensures that the resulting URN is a globally unique URI. This document modifies the syntax of the NSS to allow the following characters: "/", "~", and "&". In particular, allowing the "/" character effectively makes it possible to encapsulate hierarchical identifiers from other naming systems. For instance, consider the hypothetical example of a hierarchical naming system in which the identifiers take the form of a series of numbers separated by the "/" character, such as "1/406/47452/2". If the naming authority for such identifiers were to use URNs, it would be natural to place the existing identifiers in the NSS, resulting in URNs such as "urn:example:1/406/47452/2". However, the foregoing changes to the syntax for the NSS do not modify the encoding rules for URN namespaces that were defined in accordance with [RFC2141]. Percent-encoded octets in the NSS, for example, are in UTF-8 [UNICODE] [RFC3629]. If any such URN namespace that is used outside of the URN context (i.e., as a standalone identifier space) also allows the use of "/", "~", or "&" in the native form within that identifier space, then the encoding rules for that namespace are not changed by this specification. * Depending on the rules governing a namespace, names that are valid in a namespace might contain characters that are not allowed by the "pchar" production referenced above (e.g., characters outside the ASCII range or, consistent with the restrictions in RFC 3986, the characters "/", "?", "#", "[", and "]"). While such a string might be a valid name, it is not a valid URN until it has been translated into a conformant NSS. In the case of URNs that are formed from names that exist separately in a standalone identifier space, translation of an identifier from its "native" format to URN format is accomplished by using the canonicalization and encoding methods defined for that URN namespace. Software that is not aware of those namespace-specific canonicalization and encoding rules MUST NOT construct URNs from the names in the standalone identifier space. In order to make URNs as stable and persistent as possible when protocols evolve and the environment around them changes, namespaces SHOULD NOT allow characters beyond ASCII [RFC20] unless the nature of the particular namespace makes such characters necessary. *** Go for vote. Sean * This paragraph, in my opinion, needs a lot of editorial work but if I = contribute to that it will be in a separate message since the editorial = changes are not germane to this thread.= --Apple-Mail=_8A606806-C735-4AE4-9BE8-D02823EE469F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252



Sent from my = iPhone

On Dec 2, 2015, at 3:08 PM, Sean Leonard <dev+ietf@seantek.com> = wrote:



If an NSS is not UTF-8 encoded, it is = not conforming with RFC 2141.

It = doesn't matter, and that's not a good excuse for breaking non confirming = URNs that might = exist.

Remind me: what = is the point of writing a standard that bends over backwards for non = conforming URNs, when they never conformed in the first = place?

It just seems that this WG or the chairs = need to decide if the NSS is UTF-8 encoded or not. Or if it=92s some = convoluted = well-things-not-in-pchar-are-something-else-but-we-cannot-agree-on-anythin= g-so-we-will-make-the-world-more-convoluted-instead-of-actually-something-= that-works-like-UTF-8.

The text of RFC 2141 = Section 2.2 has a counterpart in urnbis Section 3.2, but the actual text = is markedly different. The RFC 2141 text has already been = quoted.

Here is proposed text for urnbis, in = bold. Note that there are only two small = changes.

***
3.2.  =
Namespace Specific String


   The namespace specific string (NSS) is a unique identifier that =
is
   assigned and =
managed in a consistent way and that conforms to the
   definition of the relevant namespace.  The combination of the NID
   (unique across the entire "urn" scheme) and the NSS (unique within
   the namespace) ensures that the resulting URN is a globally unique
   URI.


   This document =
modifies the syntax of the NSS to allow the following
   characters: "/", "~", and "&".  In particular, allowing the "/"
   character effectively makes it possible to encapsulate hierarchical
   identifiers from other naming systems.  For instance, consider the
   hypothetical example of a hierarchical naming system in which the
   identifiers take the form of a series of numbers separated by the "/"
   character, such as "1/406/47452/2".  If the naming authority for such
   identifiers were to use URNs, it would be natural to place the
   existing identifiers in the NSS, resulting in URNs such as
   "urn:example:1/406/47452/2".

   However, the foregoing changes to the syntax for the NSS do not
   modify the encoding rules for URN namespaces that were defined in
   accordance with [RFC2141].  Percent-encoded =
octets in the NSS,
   for example, are in UTF-8 [UNICODE] =
[RFC3629].
   If =
any such URN namespace that is used
   outside of the URN context (i.e., as a standalone identifier space)
   also allows the use of "/", "~", or "&" in the native form within
   that identifier space, then the encoding rules for that namespace are
   not changed by this specification.

*  =
Depending on the rules governing a namespace, names that are valid in
   a namespace might contain characters that are not allowed by the
   "pchar" production referenced above (e.g., characters outside the
   ASCII range or, consistent with the restrictions in RFC 3986, the
   characters "/", "?", "#", "[", and "]").  While such a string might
   be a valid name, it is not a valid URN until it has been translated
   into a conformant NSS.  In the case of URNs that are formed from
   names that exist separately in a standalone identifier space,
   translation of an identifier from its "native" format to URN format
   is accomplished by using the canonicalization and encoding methods
   defined for that URN namespace.  Software that is not aware of those
   namespace-specific canonicalization and encoding rules MUST NOT
   construct URNs from the names in the standalone identifier space.

   In order to make URNs as stable and persistent as possible when
   protocols evolve and the environment around them changes, namespaces
   SHOULD NOT allow characters beyond ASCII =
[RFC20]
   =
unless the nature of the particular namespace makes such
   characters necessary.

***

Go for = vote.

Sean

* This paragraph, in my opinion, needs a lot of =
editorial work but if I contribute to that it will be in a separate =
message since the editorial changes are not germane to this =
thread.
= --Apple-Mail=_8A606806-C735-4AE4-9BE8-D02823EE469F-- --Apple-Mail=_84D0CA22-5E46-43D5-9E4D-9C68D59A5A08 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9jCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBT8wggQnoAMCAQICEBpCSs8n+cQbczyWKtueyecwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTAyMDIwMDAwMDBaFw0xNjAy MDIyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFGRlditpZXRmQHNlYW50ZWsuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz4n20qAOzUtC1oNz5zgTny0JRBE1mJZszV2s6EurahKP vku7E+utnLhcaNahAWr2oZgeCK9uhEqijaC4qLZHnGt/+lnbsQtjmMJrcFCzhDZjDOJdYzmuS2cU vZqY7YwzCG6jSfs4gwNh+29MS6faY6ucncbnfO9rBB0xu5GIdI3BzsPNYnACNlBYU7w4X4GA0/Mw NAabNhDgxU2Tw1fl5w1Vt+6xRTXBk6V93LyVZN9wBIOpr2MuhoCJLHZrLirv/mbQE5ao4pkJLR/s yYhS1Ko4MSiJmR3ugKPkxEo6DZkuJrfck36hLmtMo3yuzi7hkXmDzPKkdLlNj+Xek1GWtwIDAQAB o4IB8jCCAe4wHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFBpm5d7y 8PBT6NqnIVbfNK8hbpPGMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcG CCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7Bgwr BgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMw XQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMwgYAw WAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRkZXYraWV0ZkBzZWFudGVrLmNvbTANBgkqhkiG9w0B AQsFAAOCAQEAeIf/Nevvv10ssk0unrJb9FC8lJi41sSpq5AFYtmC8IXwUmNxL7L5uE3tGlNJVoTK ZvGeklYWDRCzq6zqte221TowXYmFO7G27rJZbQRjLzQoY63rMlFPFrjqQCEA6rDgo9DlFO9/81P7 ZC7xvZ52WH7e3p/yJNA4Av8E0eeavhC+l+cwtrw0wCp3gUs5xJT0koGVvli2wR18zecG3ib3ml+G nDDv2AH7OhcyhVoj6V9AeGQa2HqaVpOQVRUNPamqr3xeARKk5sUSeBvxlF+0FWhl+AnhqNdxmeEp qpgSvbcS1jbTsqApvgsBcDzjC09wV8mtBoMCtqlHvF3YY2z55jGCA8MwggO/AgEBMIGwMIGbMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtueyecw CQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTUxMjAyMjI0MjExWjAjBgkqhkiG9w0BCQQxFgQUd6lVWRsujQFiL8IJyHDvmlbWb4gwgcEGCSsG AQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhAaQkrPJ/nEG3M8lirbnsnnMIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqGSIb3DQEB AQUABIIBADACkbVJo5JbsPfh587N30wymZMqsftDdLFJ05VjI+VVkv5BjEg7ncpu80ALLDU5Ipqs 7VtxLLpDIzgbRwmmRe8BDiNzMUZz+WKHEHPZflGxVh2Oe8nvyTSZ95PnSKGdJSv0hs08oUildAnx euLx/Ek+fh7p8JlgH9/tkwnwu1ZeNTbQx8Urypl0XbSHKo2tlJJm3x0179/+lmX2Nftj0oav8OSL hl991wHh00Scc3nPG/s0klulSQ+9QpYEsanahnbvnVv6BE/5SYieGtvQcY2XHWIaC5h14dLcWTcE 1QTLzKyGZ1VzAx3kZ48NvRzGCsLS4WzexOQtMVrxj282ImcAAAAAAAA= --Apple-Mail=_84D0CA22-5E46-43D5-9E4D-9C68D59A5A08-- From nobody Wed Dec 2 16:21:33 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 163F61B2ED8 for ; Wed, 2 Dec 2015 16:21:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5-MOSoRNJAe for ; Wed, 2 Dec 2015 16:21:28 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 772151B2ED6 for ; Wed, 2 Dec 2015 16:21:28 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 15E3220A59 for ; Wed, 2 Dec 2015 19:21:27 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Wed, 02 Dec 2015 19:21:27 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=5RVlDHfzwjqQ+YY2Ty9sBT+D3zE=; b=WmMvm Km3z+Sa4SlytZFdoGAUfo89m4pDT/tkqgxdD/1q4njZ4mZiXlWegdGiXN+8SdmZN fmpAdjuwDQx5TznEMCH71Iage4vCbGxomDnYrqRLPIzNIwVAGafV4ACpD+G9E7Ai +lmzsrw8Kz3vmzePqEGwjLt/fP+jsVbsMB4Yy0= X-Sasl-enc: faIG+IUCDUOEwPStIt9LPguf7BmcTEdidWSIAi4g4/hV 1449102086 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 88FA968012B; Wed, 2 Dec 2015 19:21:26 -0500 (EST) To: Sean Leonard References: <5657436C.6010305@seantek.com> <565A79C5.3070405@it.aoyama.ac.jp> <1E05E4F31732434D1C78736B@JcK-HP5.jck.com> <565B74FC.6070400@andyet.net> <34744C7E83150D15D4405C1A@JcK-HP5.jck.com> <565BF649.80507@seantek.com> <565BFA93.10707@it.aoyama.ac.jp> <565C0300.3040005@seantek.com> <565C0C49.8060109@gmx.de> <565C70B7.5000709@seantek.com> <565C7688.9020008@gmx.de> <474268EC-F30A-42E7-B08C-CF731A27604C@seantek.com> <565E3C84.6090602@network-heretics.com> <275AA9AA-CD3B-409E-80B3-F591ED929231@seantek.com> From: Keith Moore Message-ID: <565F8B05.3020608@network-heretics.com> Date: Wed, 2 Dec 2015 19:21:25 -0500 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <275AA9AA-CD3B-409E-80B3-F591ED929231@seantek.com> Content-Type: multipart/alternative; boundary="------------080009000302050303090709" Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] UTF-8 ABNF Re: What Happened to UTF-8? X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 00:21:32 -0000 This is a multi-part message in MIME format. --------------080009000302050303090709 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 12/02/2015 05:41 PM, Sean Leonard wrote: > > On Dec 2, 2015, at 2:14 PM, Keith Moore > wrote: > >> >> >> Sent from my iPhone >> >> On Dec 2, 2015, at 3:08 PM, Sean Leonard > > wrote: >> >>> >>> >>> If an NSS is not UTF-8 encoded, it is not conforming with RFC 2141. >> >> It doesn't matter, and that's not a good excuse for breaking non >> confirming URNs that might exist. > > Remind me: what is the point of writing a standard that bends over > backwards for non conforming URNs, when they never conformed in the > first place? Remind me: what's the point of making a change to an established standard for long-term stable names that might invalidate some of the names already assigned? URNs are supposed to be persistent, and they can't be persistent if meddlers at IETF change the rules, even subtly, for no good reason. (and "because we can" is not a good reason) If we were seeing operational failures due to namespaces' use of encoding schemes other than UTF-8, maybe we'd need to change the rules. Even then we'd want to do it very carefully so as to minimize the harm done. But I'm not aware of any operational failures of this nature. And if there were some, I expect that they would be the result of implementations doing things with URNs that they shouldn't do - like trying to pick apart an NSS without having a specification from the namespace for exactly how their NSSs are constructed. > > It just seems that this WG or the chairs need to decide if the NSS is > UTF-8 encoded or not. Or if it’s some convoluted > well-things-not-in-pchar-are-something-else-but-we-cannot-agree-on-anything-so-we-will-make-the-world-more-convoluted-instead-of-actually-something-that-works-like-UTF-8. > > The text of RFC 2141 Section 2.2 has a counterpart in urnbis Section > 3.2, but the actual text is markedly different. The RFC 2141 text has > already been quoted. > > Here is proposed text for urnbis, in *bold*. Note that there are only > two small changes. > > *** > > > 3.2 > . > Namespace Specific String > > > > The namespace specific string (NSS) is a unique identifier that is > assigned and managed in a consistent way and that conforms to the > definition of the relevant namespace. The combination of the NID > (unique across the entire "urn" scheme) and the NSS (unique within > the namespace) ensures that the resulting URN is a globally unique > URI. > > This document modifies the syntax of the NSS to allow the following > characters: "/", "~", and "&". In particular, allowing the "/" > character effectively makes it possible to encapsulate hierarchical > identifiers from other naming systems. For instance, consider the > hypothetical example of a hierarchical naming system in which the > identifiers take the form of a series of numbers separated by the "/" > character, such as "1/406/47452/2". If the naming authority for such > identifiers were to use URNs, it would be natural to place the > existing identifiers in the NSS, resulting in URNs such as > "urn:example:1/406/47452/2". > > However, the foregoing changes to the syntax for the NSS do not > modify the encoding rules for URN namespaces that were defined in > accordance with [RFC2141 ].*Percent-encoded octets in the NSS,* > *for example, **are in UTF-8 [UNICODE] [RFC3629].* No. This is specifying things in the wrong way, and improper layering. The burden of using UTF-8 is with the namespace, and the namespace alone. The text implies that client implementations should be able to assume that percent-encoded strings in URNs are in UTF-8, and they really shouldn't assume that at all. Actually I recommend that the preceding sentence be modified to read: However, the foregoing changes to the syntax for the NSS do not modify the encoding rules for existing URN namespaces. Because it really doesn't matter to a client how a NSS was derived from a legacy name, and it doesn't matter whether that was done according to the rules in RFC2141. If a namespace screwed up and derived its names in a different way, we still don't want to invalidate those names. * * > In order to make URNs as stable and persistent as possible when > protocols evolve and the environment around them changes, namespaces > SHOULD NOT allow characters *beyond ASCII [RFC20]* > unless the nature of the particular namespace makes such > characters necessary. I'm ambivalent about this proposal. > > > Go for vote. We don't vote in IETF. Keith --------------080009000302050303090709 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 12/02/2015 05:41 PM, Sean Leonard wrote:

On Dec 2, 2015, at 2:14 PM, Keith Moore <moore@network-heretics.com> wrote:



Sent from my iPhone

On Dec 2, 2015, at 3:08 PM, Sean Leonard <dev+ietf@seantek.com> wrote:



If an NSS is not UTF-8 encoded, it is not conforming with RFC 2141.

It doesn't matter, and that's not a good excuse for breaking non confirming URNs that might exist.

Remind me: what is the point of writing a standard that bends over backwards for non conforming URNs, when they never conformed in the first place?

Remind me: what's the point of making a change to an established standard for long-term stable names that might invalidate some of the names already assigned?   URNs are supposed to be persistent, and they can't be persistent if meddlers at IETF change the rules, even subtly, for no good reason.    (and "because we can" is not a good reason)

If we were seeing operational failures due to namespaces' use of encoding schemes other than UTF-8, maybe we'd need to change the rules.  Even then we'd want to do it very carefully so as to minimize the harm done.   But I'm not aware of any operational failures of this nature.  And if there were some, I expect that they would be the result of implementations doing things with URNs that they shouldn't do - like trying to pick apart an NSS without having a specification from the namespace for exactly how their NSSs are constructed.


It just seems that this WG or the chairs need to decide if the NSS is UTF-8 encoded or not. Or if it’s some convoluted well-things-not-in-pchar-are-something-else-but-we-cannot-agree-on-anything-so-we-will-make-the-world-more-convoluted-instead-of-actually-something-that-works-like-UTF-8.

The text of RFC 2141 Section 2.2 has a counterpart in urnbis Section 3.2, but the actual text is markedly different. The RFC 2141 text has already been quoted.

Here is proposed text for urnbis, in bold. Note that there are only two small changes.

***
3.2.  Namespace Specific String


   The namespace specific string (NSS) is a unique identifier that is
   assigned and managed in a consistent way and that conforms to the
   definition of the relevant namespace.  The combination of the NID
   (unique across the entire "urn" scheme) and the NSS (unique within
   the namespace) ensures that the resulting URN is a globally unique
   URI.


   This document modifies the syntax of the NSS to allow the following
   characters: "/", "~", and "&".  In particular, allowing the "/"
   character effectively makes it possible to encapsulate hierarchical
   identifiers from other naming systems.  For instance, consider the
   hypothetical example of a hierarchical naming system in which the
   identifiers take the form of a series of numbers separated by the "/"
   character, such as "1/406/47452/2".  If the naming authority for such
   identifiers were to use URNs, it would be natural to place the
   existing identifiers in the NSS, resulting in URNs such as
   "urn:example:1/406/47452/2".

   However, the foregoing changes to the syntax for the NSS do not
   modify the encoding rules for URN namespaces that were defined in
   accordance with [RFC2141].  Percent-encoded octets in the NSS,
   for example, are in UTF-8 [UNICODE] [RFC3629].

No.   This is specifying things in the wrong way, and improper layering.   The burden of using UTF-8 is with the namespace, and the namespace alone.  The text implies that client implementations should be able to assume that percent-encoded strings in URNs are in UTF-8, and they really shouldn't assume that at all.

Actually I recommend that the preceding sentence be modified to read:

   However, the foregoing changes to the syntax for the NSS do not
   modify the encoding rules for existing URN namespaces.

Because it really doesn't matter to a client how a NSS was derived from a legacy name, and it doesn't matter whether that was done according to the rules in RFC2141.  If a namespace screwed up and derived its names in a different way, we still don't want to invalidate those names.

 
   
   In order to make URNs as stable and persistent as possible when
   protocols evolve and the environment around them changes, namespaces
   SHOULD NOT allow characters beyond ASCII [RFC20]
   unless the nature of the particular namespace makes such
   characters necessary.

I'm ambivalent about this proposal.



Go for vote.

We don't vote in IETF.

Keith


--------------080009000302050303090709-- From nobody Thu Dec 3 01:16:00 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD441B3323 for ; Thu, 3 Dec 2015 01:15:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VA5URxkp9Wfw for ; Thu, 3 Dec 2015 01:15:58 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E75611B3211 for ; Thu, 3 Dec 2015 01:15:57 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7BCA7509BB; Thu, 3 Dec 2015 04:15:56 -0500 (EST) To: Keith Moore References: <5657436C.6010305@seantek.com> <565A79C5.3070405@it.aoyama.ac.jp> <1E05E4F31732434D1C78736B@JcK-HP5.jck.com> <565B74FC.6070400@andyet.net> <34744C7E83150D15D4405C1A@JcK-HP5.jck.com> <565BF649.80507@seantek.com> <565BFA93.10707@it.aoyama.ac.jp> <565C0300.3040005@seantek.com> <565C0C49.8060109@gmx.de> <565C70B7.5000709@seantek.com> <565C7688.9020008@gmx.de> <474268EC-F30A-42E7-B08C-CF731A27604C@seantek.com> <565E3C84.6090602@network-heretics.com> <275AA9AA-CD3B-409E-80B3-F591ED929231@seantek.com> <565F8B05.3020608@network-heretics.com> From: Sean Leonard X-Priority: Normal Message-ID: <566007D2.1040408@seantek.com> Date: Thu, 3 Dec 2015 01:13:54 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <565F8B05.3020608@network-heretics.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010906020601060906010303" Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] UTF-8 ABNF Re: What Happened to UTF-8? X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 09:15:59 -0000 This is a cryptographically signed message in MIME format. --------------ms010906020601060906010303 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 12/2/2015 4:21 PM, Keith Moore wrote: > On 12/02/2015 05:41 PM, Sean Leonard wrote: >> > >> >> >> Go for vote. > > We don't vote in IETF. The IETF operates on rough consensus (and ideally, running code). In=20 in-person meetings, consensus can be ascertained by anonymous humming=20 (for large crowds). Then the chairs figure out whether the hums. But on=20 mailing lists, people's opinions are not anonymous. So that would be=20 what I mean by voting: you have to write in and say what you want or=20 don't want. Sean --------------ms010906020601060906010303 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfYwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU/MIIEJ6ADAgECAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMjAyMDAwMDAwWhcNMTYwMjAyMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AM+J9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgiv boRKoo2guKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftv TEun2mOrnJ3G53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecN VbfusUU1wZOlfdy8lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd 7oCj5MRKOg2ZLia33JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAfIwggHu MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQaZuXe8vDwU+ja pyFW3zSvIW6TxjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHwYDVR0RBBgwFoEUZGV2K2lldGZAc2Vh bnRlay5jb20wDQYJKoZIhvcNAQELBQADggEBAHiH/zXr779dLLJNLp6yW/RQvJSYuNbEqauQ BWLZgvCF8FJjcS+y+bhN7RpTSVaEymbxnpJWFg0Qs6us6rXtttU6MF2JhTuxtu6yWW0EYy80 KGOt6zJRTxa46kAhAOqw4KPQ5RTvf/NT+2Qu8b2edlh+3t6f8iTQOAL/BNHnmr4QvpfnMLa8 NMAqd4FLOcSU9JKBlb5YtsEdfM3nBt4m95pfhpww79gB+zoXMoVaI+lfQHhkGth6mlaTkFUV DT2pqq98XgESpObFEngb8ZRftBVoZfgJ4ajXcZnhKaqYEr23EtY207KgKb4LAXA84wtPcFfJ rQaDArapR7xd2GNs+eYxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCWCGSAFlAwQC AQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEy MDMwOTEzNTRaMC8GCSqGSIb3DQEJBDEiBCBqWKxCS07Z8vT13O+50aJon/Wjiksu3FN/htjl Z2l3sDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQGkJKzyf5xBtzPJYq257J5zCBwwYLKoZIhvcNAQkQ AgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQD EzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp bCBDQQIQGkJKzyf5xBtzPJYq257J5zANBgkqhkiG9w0BAQEFAASCAQAv2mHyDNJ/bs3eisfv hBHtAb6DjYfNxy7RRTXOm845ZBE8mbEqaCijruZZJFyMzRE0WA8k3bsKOSBSnFF6avqrLhS4 xrHmYXWCeWD769yOaSwb+cgmZrL/xkIrq9dWhxRiFJ22bOoQNIGizu9mw+V3c6mc9H2oJ/Jj g9dINqzfzXNCkwYlpPLIZ+K3jCuraVRgRNTLtSgJQMZp1gPJA+X4iJAAzwgx+SsLXVC0rkyY 2c3RAm3cvMI3BLX6rc6mf9OS+JWfS8R/uW8Y2zxl3q9rnDtYAuQwWnmFXNlBlOxndz4j5iI5 GMMUgdzmwa1CU20VybvpumXGW4lPk38JFzouAAAAAAAA --------------ms010906020601060906010303-- From nobody Thu Dec 3 01:26:40 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFCD41A1AE6 for ; Thu, 3 Dec 2015 01:26:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NfehRzSxqV3S for ; Thu, 3 Dec 2015 01:26:38 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A6681A1ADD for ; Thu, 3 Dec 2015 01:26:38 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 09E70509C1 for ; Thu, 3 Dec 2015 04:26:36 -0500 (EST) To: urn@ietf.org References: <5657436C.6010305@seantek.com> <565A79C5.3070405@it.aoyama.ac.jp> <1E05E4F31732434D1C78736B@JcK-HP5.jck.com> <565B74FC.6070400@andyet.net> <34744C7E83150D15D4405C1A@JcK-HP5.jck.com> <565BF649.80507@seantek.com> <565BFA93.10707@it.aoyama.ac.jp> <565C0300.3040005@seantek.com> <565C0C49.8060109@gmx.de> <565C70B7.5000709@seantek.com> <565C7688.9020008@gmx.de> <474268EC-F30A-42E7-B08C-CF731A27604C@seantek.com> <565E3C84.6090602@network-heretics.com> <275AA9AA-CD3B-409E-80B3-F591ED929231@seantek.com> <565F8B05.3020608@network-heretics.com> <566007D2.1040408@seantek.com> From: Sean Leonard Message-ID: <56600A53.5020102@seantek.com> Date: Thu, 3 Dec 2015 01:24:35 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <566007D2.1040408@seantek.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050902030906080806080006" Archived-At: Subject: Re: [urn] UTF-8 ABNF Re: What Happened to UTF-8? X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 09:26:40 -0000 This is a cryptographically signed message in MIME format. --------------ms050902030906080806080006 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 12/3/2015 1:13 AM, Sean Leonard wrote: > On 12/2/2015 4:21 PM, Keith Moore wrote: >> On 12/02/2015 05:41 PM, Sean Leonard wrote: >>> >> >>> >>> >>> Go for vote. >> >> We don't vote in IETF. > Corrected: > The IETF operates on rough consensus (and ideally, running code). In=20 > in-person meetings, consensus can be ascertained by anonymous humming=20 > (for large crowds). Then the chairs figure out whether the hums are=20 > pointing to rough consensus in one direction or another. But on=20 > mailing lists, people's opinions are not anonymous. So that would be=20 > what I mean by voting: you have to write in and say what you want or=20 > don't want. > > Sean --------------ms050902030906080806080006 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfYwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU/MIIEJ6ADAgECAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMjAyMDAwMDAwWhcNMTYwMjAyMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AM+J9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgiv boRKoo2guKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftv TEun2mOrnJ3G53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecN VbfusUU1wZOlfdy8lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd 7oCj5MRKOg2ZLia33JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAfIwggHu MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQaZuXe8vDwU+ja pyFW3zSvIW6TxjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHwYDVR0RBBgwFoEUZGV2K2lldGZAc2Vh bnRlay5jb20wDQYJKoZIhvcNAQELBQADggEBAHiH/zXr779dLLJNLp6yW/RQvJSYuNbEqauQ BWLZgvCF8FJjcS+y+bhN7RpTSVaEymbxnpJWFg0Qs6us6rXtttU6MF2JhTuxtu6yWW0EYy80 KGOt6zJRTxa46kAhAOqw4KPQ5RTvf/NT+2Qu8b2edlh+3t6f8iTQOAL/BNHnmr4QvpfnMLa8 NMAqd4FLOcSU9JKBlb5YtsEdfM3nBt4m95pfhpww79gB+zoXMoVaI+lfQHhkGth6mlaTkFUV DT2pqq98XgESpObFEngb8ZRftBVoZfgJ4ajXcZnhKaqYEr23EtY207KgKb4LAXA84wtPcFfJ rQaDArapR7xd2GNs+eYxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCWCGSAFlAwQC AQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEy MDMwOTI0MzVaMC8GCSqGSIb3DQEJBDEiBCBVZ1eT3oIbm2Yltk6Wf3nbst3CMfQmzLHt7F8f Z14zCzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQGkJKzyf5xBtzPJYq257J5zCBwwYLKoZIhvcNAQkQ AgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQD EzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp bCBDQQIQGkJKzyf5xBtzPJYq257J5zANBgkqhkiG9w0BAQEFAASCAQAfkZzXmXmvhpLzHmQq qyk0m6MAisXW3olQd7EKGGCh8lOYYvHt/pka2qPVdf8Ps2jV0uybbltAfwvcDSiqeTHuqNaO aEiRYfjOusDGJ/GgFbjEc73Sr5x7YUnz+x3rWaSv7r6KuI6a11wmagyJT3M/OJaa0RPoBIs7 uWK25UyNkXB2E1S0McgzBL7sJB8gXFQEdikjp2l+PCTqkAnNRwhAyKJMLpMcrBG423kE4F3m +S5BG6Ohue+cAAQsPu1Q7p69ZBoQt0GioU7y5AiyPQ7iGBR2k9443Ch+8NKsWg950pdh3hv8 4iT+aahFlCjqFJvE12FF7hZWU8B1yVKh23eNAAAAAAAA --------------ms050902030906080806080006-- From nobody Thu Dec 3 10:09:57 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2731A8FD4 for ; Thu, 3 Dec 2015 10:09:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxraCNozyJtn for ; Thu, 3 Dec 2015 10:09:54 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6049B1A8BC2 for ; Thu, 3 Dec 2015 10:09:54 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 425CC509C3 for ; Thu, 3 Dec 2015 13:09:52 -0500 (EST) To: "urn@ietf.org" References: <5657436C.6010305@seantek.com> <565A79C5.3070405@it.aoyama.ac.jp> <1E05E4F31732434D1C78736B@JcK-HP5.jck.com> <565B74FC.6070400@andyet.net> <34744C7E83150D15D4405C1A@JcK-HP5.jck.com> <565BF649.80507@seantek.com> <565BFA93.10707@it.aoyama.ac.jp> <565C0300.3040005@seantek.com> <565C0C49.8060109@gmx.de> <565C70B7.5000709@seantek.com> <565C7688.9020008@gmx.de> <474268EC-F30A-42E7-B08C-CF731A27604C@seantek.com> <565E3C84.6090602@network-heretics.com> <275AA9AA-CD3B-409E-80B3-F591ED929231@seantek.com> <565F8B05.3020608@network-heretics.com> From: Sean Leonard Message-ID: <566084F7.9000009@seantek.com> Date: Thu, 3 Dec 2015 10:07:51 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <565F8B05.3020608@network-heretics.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020006000202000200040405" Archived-At: Subject: Re: [urn] UTF-8 ABNF Re: What Happened to UTF-8? X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 18:09:56 -0000 This is a cryptographically signed message in MIME format. --------------ms020006000202000200040405 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Good news! I reviewed every URN registration, formal and informal, in the IANA URN=20 Namespaces registry [1]. Every single one was registered under the rules = of RFC 2141 / RFC 3406, after those were standardized. So that includes=20 UTF-8 encoding. RFC 2141 is the operating standard and has the IETF consensus; all=20 namespace registrants are bound to follow it, including UTF-8 encoding.=20 There is no evidence that any namespace registrants are bound to prior=20 or different rules. If you want to change the UTF-8 part of RFC 2141=20 [bis], it needs a different IETF consensus. Otherwise this whole UTF-8=20 issue is just an editorial matter. Should anyone have a different view, documented evidence is necessary to = construct a credible argument. Implementers can rely on the premise that the NSS percent-encoded=20 characters are UTF-8 encoded. (Conveniently that makes IRIs directly=20 transposable, at least for the NSS component. The other proposed=20 components like f-, q-, and r-, not necessarily, but that's=20 out-of-scope.) URNs are supposed to be persistent, and they can't be=20 persistent if meddlers at IETF change the rules, even subtly, for no=20 good reason. Regards, Sean [1] http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml --------------ms020006000202000200040405 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfYwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU/MIIEJ6ADAgECAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMjAyMDAwMDAwWhcNMTYwMjAyMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AM+J9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgiv boRKoo2guKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftv TEun2mOrnJ3G53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecN VbfusUU1wZOlfdy8lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd 7oCj5MRKOg2ZLia33JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAfIwggHu MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQaZuXe8vDwU+ja pyFW3zSvIW6TxjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHwYDVR0RBBgwFoEUZGV2K2lldGZAc2Vh bnRlay5jb20wDQYJKoZIhvcNAQELBQADggEBAHiH/zXr779dLLJNLp6yW/RQvJSYuNbEqauQ BWLZgvCF8FJjcS+y+bhN7RpTSVaEymbxnpJWFg0Qs6us6rXtttU6MF2JhTuxtu6yWW0EYy80 KGOt6zJRTxa46kAhAOqw4KPQ5RTvf/NT+2Qu8b2edlh+3t6f8iTQOAL/BNHnmr4QvpfnMLa8 NMAqd4FLOcSU9JKBlb5YtsEdfM3nBt4m95pfhpww79gB+zoXMoVaI+lfQHhkGth6mlaTkFUV DT2pqq98XgESpObFEngb8ZRftBVoZfgJ4ajXcZnhKaqYEr23EtY207KgKb4LAXA84wtPcFfJ rQaDArapR7xd2GNs+eYxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCWCGSAFlAwQC AQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEy MDMxODA3NTFaMC8GCSqGSIb3DQEJBDEiBCBFbvLAMBK2AXA4oAtnVXrmPZmGD0qLArk3hQIL /P51hTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQGkJKzyf5xBtzPJYq257J5zCBwwYLKoZIhvcNAQkQ AgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQD EzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp bCBDQQIQGkJKzyf5xBtzPJYq257J5zANBgkqhkiG9w0BAQEFAASCAQCSfrmmntwxsJ9OcqFD Z13Tc+y0IdcLK6KAJmlg7IJEDlznpVIdkoe/ybSQ29/5RA6WOpgBnODns76wpTD9Jj6o3cZB nNZGfFiIr3NizkLWNWVjWjthq3D9SzT+Jgks+tAcUVBx5c/6Idnb/I0nKuIynuVqQaHGKTfH /dkVVI9gWTL9vuB78azYawW7LjiurnTzlE5Uq0DyDTwjg4Z7lzfaAZ0aROuuB3iCm+5mAeDB 6m30aRhq6fNRDg+5JPDrMfLT2Vy0CshagHFnelePO5vtilYIxd1eV7/U5htNyiLhzM4u0Vjr g8lF6HP14vY9l7WpR2QTggWZW+8tC6//4FwkAAAAAAAA --------------ms020006000202000200040405-- From nobody Thu Dec 3 23:07:59 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C342A1B2E54 for ; Thu, 3 Dec 2015 23:07:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.902 X-Spam-Level: X-Spam-Status: No, score=-3.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8DpgExy0kAw0 for ; Thu, 3 Dec 2015 23:07:50 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0721.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::721]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CF9F1B2E55 for ; Thu, 3 Dec 2015 23:07:48 -0800 (PST) Received: from AMSPR07MB454.eurprd07.prod.outlook.com (10.242.106.145) by AMSPR07MB453.eurprd07.prod.outlook.com (10.242.106.143) with Microsoft SMTP Server (TLS) id 15.1.331.20; Fri, 4 Dec 2015 07:07:29 +0000 Received: from AMSPR07MB454.eurprd07.prod.outlook.com ([10.242.106.145]) by AMSPR07MB454.eurprd07.prod.outlook.com ([10.242.106.145]) with mapi id 15.01.0331.023; Fri, 4 Dec 2015 07:07:29 +0000 From: "Hakala, Juha E" To: Sean Leonard , "urn@ietf.org" Thread-Topic: Unicode, UTF-8 and persistent identifiers Thread-Index: AdEuXj+0O9y6O46LSvq+7tkow0bCAA== Date: Fri, 4 Dec 2015 07:07:28 +0000 Message-ID: Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=juha.hakala@helsinki.fi; x-originating-ip: [128.214.71.222] x-microsoft-exchange-diagnostics: 1; AMSPR07MB453; 5:30HcBoStCugf07Xp7JurY3X4BCsEIOr3cqn3dnWcpet4InhJKrfur4uWwOIxYd2iGp6hVoQYOKrwOQ5Ulb8stcNXayuyOu/w36yNxuCJzImSzGnXS1oHzl/xzzUKvRF+yLfJ8VBtwMyzXAag3PJylg==; 24:Q20KgDa+pxgKNnyuhBFJPytcGBFeje0IafVbMPmrmd7cwHqZo4RwTuzkVQu/lttw3Ns61Vbt0E/NGSffDfMTSRSn8lJP/SCtQLZZqpfC06E= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB453; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046); SRVR:AMSPR07MB453; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB453; x-forefront-prvs: 07807C55DC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(209900001)(199003)(13464003)(189002)(1720100001)(586003)(105586002)(66066001)(5003600100002)(77096005)(3846002)(6116002)(102836003)(15395725005)(5008740100001)(40100003)(101416001)(86362001)(106356001)(229853001)(87936001)(2900100001)(50986999)(33656002)(15975445007)(54356999)(2501003)(76576001)(74482002)(1220700001)(5004730100002)(5001960100002)(19580405001)(1096002)(74316001)(19580395003)(97736004)(81156007)(5001770100001)(10400500002)(19273905006)(5002640100001)(189998001)(92566002)(11100500001)(122556002)(563064011)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB453; H:AMSPR07MB454.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: helsinki.fi does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: helsinki.fi X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Dec 2015 07:07:29.0109 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB453 Archived-At: Cc: "llannom@cnri.reston.va.us" , Tobias Weigel Subject: [urn] Unicode, UTF-8 and persistent identifiers X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 07:07:58 -0000 Hello,=20 identifier standards always specify the characters / character set allowed.= They may also specify encoding.=20 Encoding is usually UTF-8, but characters / character sets vary. Old domain= specific standards like ISSN and ISBN used just numbers from 0 to 9 (and I= SBN also X). Generic identifier systems like ARK and Handle are more liber= al, but in different ways. ARK allows just printable ASCII characters, wher= eas Handle character set includes all printable Unicode characters. The way= this is specified in RFC 3650 is a bit careless:=20 "Handles may consist of any printable characters from the Universal Character Set (UCS-2) of ISO/IEC 10646, which is the exact character set defined by Unicode. The UCS-2 character set encompasses most characters used in every major language written today. To allow compatibility with most of the existing systems and to prevent ambiguity among different encodings, the Handle System protocol mandates UTF-8 to be the only encoding used for handles." UCS-2 is not a character set, but an obsolete encoding which became UTF-16 = when a mechanism to support planes beyond Unicode BMP was added. UCS-2 and = UTF-8 are not compatible, so methinks RFC 3650 was not prepared as carefull= y as rfc2141bis ;-). As an aside, Handle community has not updated the char= acter set related documentation; the latest version of the Handle technical= manual (from 2010) says=20 "Handles may consist of any printable characters from the Universal Charact= er Set, two-octet form (UCS-2) of ISO/IEC 10646, which is the exact character set defined by Unicode v2.0." It is not obvious for me what "printable character" means in the context of= Unicode. Definitely exclusion of all Unicode control characters, but what = about for instance emojis? There were none in Unicode 3.0, but Unicode 8.0 = has about 1200, and IMO identifiers containing emojis should not be allowed= at all. One reason for such exclusion is that different operating systems = and applications may have different symbols for the same emoji. For instanc= e, heavy black heart is actually often red:=20 http://apps.timwhitlock.info/emoji/tables/unicode =20 Other issues include diacritics without their host characters. And should o= nly precomposed versions of characters like a mit umlaut be allowed, or is = it OK to have them both in decomposed and precomposed forms? Generally, wha= t can and should be said in the Handle/URN/DOI syntax?=20 The lesson to learn from RFC3650? Although this part of the Handle document= ation is both a bit confusing and out of date, Handle is the most widely us= ed persistent identifier system out there. Millions and millions of Handles= have been assigned, they serve the users just fine, and I have not seen an= y complaints about the Handle character set & encoding specification being = both erroneous and out of date. So I think URNBIS should not spend plenty o= f time and effort in trying to make character set / character encoding rela= ted parts of rfc2141bis perfect; good will do. Of course, it would be nice = if Handle documentation were up to date since eventually some people may st= art having questions about what is OK and what isn't.=20 AFAIK the biggest issue with allowing (printable) Unicode characters in URN= s is security. According to Unicode confusables utility, simple identifier = like "abc" has 9072 different variants when printed:=20 http://unicode.org/cldr/utility/confusables.jsp?a=3Dabc&r=3DNone=20 and "123" has more than 10.000 variants. Computers will be able to tell the= m apart (unless they rely on OCR), but humans may have problems.=20 It is easy to check if standard identifier like ISBN is correct. If a singl= e number "3" in an ISBN is replaced with Cyrillic capital letter ZE which i= n some fonts looks just the same, ISBN parser knows that this "ISBN" is not= correct and a link based on might lead users astray. With Handle system, r= eplacing number 3 with ZE is fine according to the Handle specification, so= no generic Handle parser is able to turn such identifier down. In practice= , some Handle prefixes may have their own, much limited character set speci= fications, and they may parse their Handles according to these specs.=20 I am not sure if we should say more about security in rfc2141bis. We alread= y have a reference to RFC6943 which may be sufficient (see especially chapt= er 4.2 in that RFC). Another link might be added to Unicode confusables pag= e. And it might be useful to say that as a rule security issues increase wh= en character set allowed grows since then the confusables such as Cyrillic = ZE replacing "3" are harder to detect. =20 =20 All the best,=20 =20 Juha > -----Original Message----- > From: urn [mailto:urn-bounces@ietf.org] On Behalf Of Sean Leonard > Sent: 3. joulukuuta 2015 20:08 > To: urn@ietf.org > Subject: Re: [urn] UTF-8 ABNF Re: What Happened to UTF-8? >=20 > Good news! >=20 > I reviewed every URN registration, formal and informal, in the IANA URN > Namespaces registry [1]. Every single one was registered under the rules = of > RFC 2141 / RFC 3406, after those were standardized. So that includes > UTF-8 encoding. >=20 > RFC 2141 is the operating standard and has the IETF consensus; all > namespace registrants are bound to follow it, including UTF-8 encoding. > There is no evidence that any namespace registrants are bound to prior or > different rules. If you want to change the UTF-8 part of RFC 2141 [bis], = it > needs a different IETF consensus. Otherwise this whole UTF-8 issue is jus= t an > editorial matter. >=20 > Should anyone have a different view, documented evidence is necessary to > construct a credible argument. >=20 > Implementers can rely on the premise that the NSS percent-encoded > characters are UTF-8 encoded. (Conveniently that makes IRIs directly > transposable, at least for the NSS component. The other proposed > components like f-, q-, and r-, not necessarily, but that's > out-of-scope.) URNs are supposed to be persistent, and they can't be > persistent if meddlers at IETF change the rules, even subtly, for no good > reason. >=20 > Regards, >=20 > Sean >=20 > [1] http://www.iana.org/assignments/urn-namespaces/urn- > namespaces.xhtml >=20 From nobody Fri Dec 4 05:32:57 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E98E41B316D for ; Fri, 4 Dec 2015 05:32:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQRWVVirLZYk for ; Fri, 4 Dec 2015 05:32:54 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D4981A8706 for ; Fri, 4 Dec 2015 05:32:53 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id E3B37207D8 for ; Fri, 4 Dec 2015 08:32:52 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Fri, 04 Dec 2015 08:32:52 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=g8ay5G/LDrysixg qBGEiIiLXvBA=; b=iyJpceBCZQSFmCyo7wkw9SzvweNY403j9FJZLaPcuHhUXiS m2mQdiyBtb/XbhKSwZz/utRVj6Q53j3HxswMNQBwvhQ4kPqzEwQRYxulNR1UAa38 zH244D5BSD+iUVJFTlIlfgkRf8p4VLCmDuiAvawq222B+jZ/Z0ALRSPJjaBw= X-Sasl-enc: VUJyCB8SQucfi6vcYSEri3KiwuyrizNzvHtbGtfCsuKK 1449235972 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 8B5376800D6; Fri, 4 Dec 2015 08:32:52 -0500 (EST) To: urn@ietf.org References: <5657436C.6010305@seantek.com> <565A79C5.3070405@it.aoyama.ac.jp> <1E05E4F31732434D1C78736B@JcK-HP5.jck.com> <565B74FC.6070400@andyet.net> <34744C7E83150D15D4405C1A@JcK-HP5.jck.com> <565BF649.80507@seantek.com> <565BFA93.10707@it.aoyama.ac.jp> <565C0300.3040005@seantek.com> <565C0C49.8060109@gmx.de> <565C70B7.5000709@seantek.com> <565C7688.9020008@gmx.de> <474268EC-F30A-42E7-B08C-CF731A27604C@seantek.com> <565E3C84.6090602@network-heretics.com> <275AA9AA-CD3B-409E-80B3-F591ED929231@seantek.com> <565F8B05.3020608@network-heretics.com> <566084F7.9000009@seantek.com> From: Keith Moore Message-ID: <566195FE.5050308@network-heretics.com> Date: Fri, 4 Dec 2015 08:32:46 -0500 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <566084F7.9000009@seantek.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] UTF-8 ABNF Re: What Happened to UTF-8? X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 13:32:56 -0000 On 12/03/2015 01:07 PM, Sean Leonard wrote: > Good news! > > I reviewed every URN registration, formal and informal, in the IANA > URN Namespaces registry [1]. Every single one was registered under the > rules of RFC 2141 / RFC 3406, after those were standardized. So that > includes UTF-8 encoding. > > RFC 2141 is the operating standard and has the IETF consensus; all > namespace registrants are bound to follow it, including UTF-8 > encoding. There is no evidence that any namespace registrants are > bound to prior or different rules. If you want to change the UTF-8 > part of RFC 2141 [bis], it needs a different IETF consensus. Otherwise > this whole UTF-8 issue is just an editorial matter. > > Should anyone have a different view, documented evidence is necessary > to construct a credible argument. > > Implementers can rely on the premise that the NSS percent-encoded > characters are UTF-8 encoded. (Conveniently that makes IRIs directly > transposable, at least for the NSS component. The other proposed > components like f-, q-, and r-, not necessarily, but that's > out-of-scope.) URNs are supposed to be persistent, and they can't be > persistent if meddlers at IETF change the rules, even subtly, for no > good reason. Disagree. Not convinced, for reasons cited earlier. Not going to keep repeating myself either. Keith From nobody Thu Dec 10 06:20:52 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 310661B2BBB for ; Thu, 10 Dec 2015 06:20:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.422 X-Spam-Level: * X-Spam-Status: No, score=1.422 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cszUo9XRBlgA for ; Thu, 10 Dec 2015 06:20:48 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56D7B1B2BBF for ; Thu, 10 Dec 2015 06:20:40 -0800 (PST) Received: by mail-wm0-x22d.google.com with SMTP id u63so25972057wmu.0 for ; Thu, 10 Dec 2015 06:20:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hxr-us.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:content-type; bh=00FpJ37X7EaQYmE+zvbM0bJbGDEViB9eyJ+ETUBJPfI=; b=tNQQAyLdWUky8Gimd4Swkiccemfw/VJhOvYRmCxa3j2YuAQWQJbfShI0Au2wOYPWFs xUFbcs10oTNBqn6Y5niPummJajnmwSOTnUf3YhxR/M937Mcom69fQDOZonU877LEJBdN JngqCCgKyT3gVRf7tsjBUDL/HI8vwYUNGOnBscTljBFB0tSbtyKKVRa2ojPVFWKDI7NL 84LIpt0JK3tu561md7+0bODEUiSzOIaPFC07LXCBgFFZZb40lLcGfSV8cY2QOnMjUg0Z y9Epj/2uBpWlxkbDXlRDpHqninOMSv8yivHWXREPuEisi4vxjLLcLOPCu2M6760wCeYf WNNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=00FpJ37X7EaQYmE+zvbM0bJbGDEViB9eyJ+ETUBJPfI=; b=IJjp0gGlT/PUP47q5jfefqh3JireKamvmFqYMlFXOQTxzgBXddkHceDk6idqsHTNf0 qzel8aKFjGOnc8838gcJSQy6YDx6+ogTkePqsD7jsy4dtcYpJD+IZEetulFwIl4Vc82l CB+nhBr7ZjTMydj5ZIv/Xxxthtx87aio+lwlNwwQKIgvLE+0xEwLrVK0e90j/oQx8RMr NC4Q323VmOjJvcHfbdfsY/v1dgBjBBR16mNywa6tVIAqvpkG24z0KDGIQgXjabmMGeiQ qts8/2EnUkKeiv7v0LQiIgdiAfAfq33ywtI24GwGGecxhItdkQ4wb/1qvN5y9f0s1DXd oSMw== X-Gm-Message-State: ALoCoQmA68V3P7psxj8+U+TySMxVgKol6BLjTo0lbxw/ybavYWxXnydCmkwxuhljv+5uQOk45cq974JJ40lFuVmD4UIKDoFTkA== MIME-Version: 1.0 X-Received: by 10.194.133.233 with SMTP id pf9mr13067328wjb.71.1449757238921; Thu, 10 Dec 2015 06:20:38 -0800 (PST) Received: by 10.194.91.203 with HTTP; Thu, 10 Dec 2015 06:20:38 -0800 (PST) X-Originating-IP: [2001:500:4:15:bd43:b713:17a:e5f1] Date: Thu, 10 Dec 2015 09:20:38 -0500 Message-ID: From: Andrew Newton To: "urn@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [urn] Civility and the IETF X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2015 14:20:49 -0000 All, I'd like to thank each of you for your passion on the work of this group. Without it, we would be unable to attain even the remoteness of quality that is desired. That being said, I ask that we all take note of the manner and tone of some of our messages. While the rough and tumble of the IETF is almost tradition for us, we should keep in mind that there are many silent observers, particularly of this work, who are not accustomed to this style of communication. Even though no message or person has risen to the level of requiring administrative action, and I know that each of us has seen worse on other IETF lists, it would be helpful for all of us to to examine how others might perceive our interactions. Thanks, and I hope you all enjoy the holidays. -andy, chair From nobody Thu Dec 17 05:21:47 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0FE71A8AD1; Wed, 16 Dec 2015 13:30:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jfae-BTpxnRV; Wed, 16 Dec 2015 13:30:23 -0800 (PST) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA8871A8AAB; Wed, 16 Dec 2015 13:30:22 -0800 (PST) Received: by mail-pf0-x22d.google.com with SMTP id 68so18306505pfc.1; Wed, 16 Dec 2015 13:30:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:message-id:mime-version:subject:date:references :cc:to; bh=DFLA/a1hbUCx00z6EeDo+640iSBo2pTgtTjFDyOtdIQ=; b=syRi1juamiyxRrtbMayOBzlDNqJrvRrMdhfWBynJWxGzeE83iyVy1qzwgakoOo9zBu 1U21uV1yc+trTJTolkFWO8EJ11JR7bJbZhh7UWs+7ngNBMKhdCLzJSllAVUwYNKVzFY3 A4eFTtB1oqymnPPq+4pcouT5hgtS3pNE23vEsKFGfNsZBJrxvDW0EQbYA9dy6oM5C5XY gSpvoMCCsmphx3+ct0Md7EYuuOvx5A1tUvd1qoJgfwBJdLWeAAcCmLIia/gd+6Yah8O3 Ycub7WGDgIKEMGh7EU1v2HN0xhaucCO8RcWsPOZMaHIs0PCOvn38pW5bLB+BYz1QIsB3 4prw== X-Received: by 10.98.14.29 with SMTP id w29mr6377260pfi.26.1450301422540; Wed, 16 Dec 2015 13:30:22 -0800 (PST) Received: from ?IPv6:2001:420:302:1330:5d53:88e9:acd0:56a5? ([2001:420:302:1330:5d53:88e9:acd0:56a5]) by smtp.gmail.com with ESMTPSA id 25sm6789720pfi.73.2015.12.16.13.30.20 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 16 Dec 2015 13:30:21 -0800 (PST) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_372A4867-5A6F-4A23-9D06-B1D170AA0315" Message-Id: <6646BF13-F14C-4CA2-A2C2-743D06148C2C@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Date: Wed, 16 Dec 2015 13:30:21 -0800 References: <20151216211745.31386.34832.idtracker@ietfa.amsl.com> To: urn-nid@apps.ietf.org, urn@ietf.org, urn-nid@ietf.org X-Mailer: Apple Mail (2.2104) Archived-At: X-Mailman-Approved-At: Thu, 17 Dec 2015 05:21:45 -0800 Cc: Benoit Claise , Jason Wolfe , Barry Leiba , "Ranganathan, Raghu" Subject: [urn] Fwd: New Version Notification for draft-mahesh-mef-urn-01.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2015 21:30:25 -0000 --Apple-Mail=_372A4867-5A6F-4A23-9D06-B1D170AA0315 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Please review the request for a URN nid. I have been made aware that = there are updates to 2141 and 3406 that might affect future allocation = of URN namespaces. But since that work is in progress and MEF is ready = to publish documents using the URN namespace, I am hoping to use the = current process. Barry, here has agreed to be the Document Shepherd, and Benoit is ready = to provide a AD sponsor on the draft. If there are any questions, please feel free to contact me. Thanks. > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-mahesh-mef-urn-01.txt > Date: December 16, 2015 at 1:17:45 PM PST > To: "Mahesh Jethanandani" >=20 >=20 > A new version of I-D, draft-mahesh-mef-urn-01.txt > has been successfully submitted by Mahesh Jethanandani and posted to = the > IETF repository. >=20 > Name: draft-mahesh-mef-urn > Revision: 01 > Title: URN Namespace for MEF Documents > Document date: 2015-12-15 > Group: Individual Submission > Pages: 5 > URL: = https://www.ietf.org/internet-drafts/draft-mahesh-mef-urn-01.txt > Status: https://datatracker.ietf.org/doc/draft-mahesh-mef-urn/ > Htmlized: https://tools.ietf.org/html/draft-mahesh-mef-urn-01 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-mahesh-mef-urn-01 >=20 > Abstract: > This document describes the Namespace Identifier (NID) 'mef' for > Uniform Resource Names (URNs) used to identify resources published = by > MEF Forum (http://www.mef.net). MEF specifies and manages resources > that utilize this URN identification model. Management activities > for these and other resources types are handled by the manager of = the > MEF Assigned Names and Numbers (MANN) registry. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_372A4867-5A6F-4A23-9D06-B1D170AA0315 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Please review the request for a URN nid. I have been made = aware that there are updates to 2141 and 3406 that might affect future = allocation of URN namespaces. But since that work is in progress and MEF = is ready to publish documents using the URN namespace, I am hoping to = use the current process.

Barry, here has agreed to be the Document Shepherd, and = Benoit is ready to provide a AD sponsor on the draft.

If there are any = questions, please feel free to contact me.

Thanks.

Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-mahesh-mef-urn-01.txt
Date: = December 16, 2015 at 1:17:45 PM = PST
To: = "Mahesh Jethanandani" <mjethanandani@gmail.com>


A new version of I-D, = draft-mahesh-mef-urn-01.txt
has been successfully = submitted by Mahesh Jethanandani and posted to the
IETF = repository.

Name: = draft-mahesh-mef-urn
Revision: 01
Title:= = URN Namespace for MEF Documents
Document date: = 2015-12-15
Group: Individual Submission
Pages:= = 5
URL: =            https://www.ietf.org/internet-drafts/draft-mahesh-mef-urn-01.tx= t
Status: =         https://datatracker.ietf.org/doc/draft-mahesh-mef-urn/
Htmlized:       https://tools.ietf.org/html/draft-mahesh-mef-urn-01
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-mahesh-mef-urn-01=

Abstract:
  This = document describes the Namespace Identifier (NID) 'mef' for
=   Uniform Resource Names (URNs) used to identify resources = published by
  MEF Forum (http://www.mef.net). =  MEF specifies and manages resources
=   that utilize this URN identification model.  Management = activities
  for these and other resources = types are handled by the manager of the
  MEF = Assigned Names and Numbers (MANN) registry.




Please note that = it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_372A4867-5A6F-4A23-9D06-B1D170AA0315-- From nobody Thu Dec 17 05:21:48 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EEEA1A8FD3 for ; Wed, 16 Dec 2015 14:18:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-4R-qK04rKM for ; Wed, 16 Dec 2015 14:18:45 -0800 (PST) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEBCD1A900A for ; Wed, 16 Dec 2015 14:18:44 -0800 (PST) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-10v.sys.comcast.net with comcast id uNJa1r0052Udklx01NJkcQ; Wed, 16 Dec 2015 22:18:44 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-18v.sys.comcast.net with comcast id uNJi1r00Q1nMCLR01NJjnT; Wed, 16 Dec 2015 22:18:44 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id tBGMIgkL029098; Wed, 16 Dec 2015 17:18:42 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id tBGMIfih029095; Wed, 16 Dec 2015 17:18:41 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Mahesh Jethanandani In-Reply-To: <6646BF13-F14C-4CA2-A2C2-743D06148C2C@gmail.com> (mjethanandani@gmail.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 16 Dec 2015 17:18:41 -0500 Message-ID: <87oadqhwam.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1450304324; bh=p1vkHMPbAfO8xa9+7sAPlKZPEMn96hJXqOd4VhJ2wjE=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=cWWdYXyJRPkXXEloM31IMxRaFtrjQ5rlIc5yL2rk6zrRYdsSciXwTMoakRc9IPPyA 7yuaiplscIhQ2Cwi50AUhSjTIlTBwhKZU1EKLT+22n3jrntcVJMXQ1DFOzu1P3pqrR TYyd04UxcCbPYbrIDSEzO0NPHT+XnsYdZcWtbBl/i+xMcKa9gavd6Vvc0BXxlnJuPi SE3bfSdut7wnuw33cpgCk6IyTufpmgPP5iG68aPolgz3BZyfICpRtYgHgaO8onvccw eVfEHi22nD/6eQll+ht8vNTbUASgYx77EbXL8bUhIG/WPZKFrHQO/8OalRcJfAIEYq /QEcbO7EVFL3g== Archived-At: X-Mailman-Approved-At: Thu, 17 Dec 2015 05:21:45 -0800 Cc: barryleiba@computer.org, urn-nid@ietf.org, jason.wolfe@bell.ca, urn-nid@apps.ietf.org, rraghu@ciena.com, bclaise@cisco.com, urn@ietf.org Subject: Re: [urn] Fwd: New Version Notification for draft-mahesh-mef-urn-01.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2015 22:18:46 -0000 Mahesh Jethanandani writes: > Please review the request for a URN nid. The -01 draft has taken care of my concerns. Dale