From nobody Wed Dec 3 16:11:42 2014 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA2581ACF73 for ; Wed, 3 Dec 2014 16:10:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 3e3NDQ4fpHiQ for ; Wed, 3 Dec 2014 16:10:55 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 428DD1ACF6A for ; Wed, 3 Dec 2014 16:10:55 -0800 (PST) Received: from host86-184-97-67.range86-184.btcentralplus.com ([86.184.97.67] helo=[192.168.1.67]) by mail4.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1XwK0T-0007Oq-Ns; Thu, 04 Dec 2014 00:10:54 +0000 Message-ID: <547FA68A.4010000@proseconsulting.co.uk> Date: Thu, 04 Dec 2014 00:10:50 +0000 From: Mark R Bannister User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Arthur de Jong , ldapext@ietf.org References: <1389133522.4574.30.camel@sorbet.thuis.net> <52CDBFD2.10905@proseconsulting.co.uk> In-Reply-To: <52CDBFD2.10905@proseconsulting.co.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailcore-Auth: 12040446 X-Mailcore-Domain: 1286164 Archived-At: http://mailarchive.ietf.org/arch/msg/ldapext/j1j2ahg3FfzcdAp3FjUNsepE4RI Subject: Re: [ldapext] DBIS - new IETF drafts X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 00:10:59 -0000 On 08/01/2014 21:14, Mark R Bannister wrote: > On 07/01/2014 22:25, Arthur de Jong wrote: >> Also, you may be interested in looking at the nss-pam-ldapd code. It >> seems to have a somewhat similar design as the ideas described in the >> DBIS Reference Implementation. There is even a work-in-progress Python >> implementation that you could replace with a DBIS implementation. >> >> Anyway, that's it for now. Perhaps I'll take a further look in a few >> days. >> > > Thanks I had a look at your code already. I may be able to re-use > some of it, possibly the NSS layer, however quite a lot of it becomes > redundant or would have to be rewritten for DBIS. I think the > architecture I have designed in dbis_cachemgr will scale better on > busy enterprise servers and will handle LDAP server outages more > gracefully, as I have worker threads that can operate on many > connections simultaneously while sharing a pool of LDAP connections. > > Best regards, > Mark. Hi Arthur et al, I have been quiet all year on the subject of DBIS as I have been busy producing a reference implementation. I am very pleased to report that the first version of a fully working reference implementation is now available: https://sourceforge.net/projects/dbis/ A brief reminder, DBIS is slated as a replacement for NIS, RFC2307 and RFC2307bis. It is highly compatible with these and should be viewed as the next evolution of them. This is written in Python, so should be highly portable, although I've developed it on OpenSuSE 12.1 and have not yet tested it on any other platform. Arthur, I have used some of your nss-pam-ldapd code, specifically the NSS library code (not the server-side). I hope you like what I've done with it. I have also made some changes to the internet drafts, many of those changes based on feedback I received from helpful folk on this mailing list at the beginning of the year. My blog from last year provides the relevant links to those drafts, with some further background reading: http://technicalprose.blogspot.co.uk/2013/08/introducing-dbis.html I look forward to receiving further feedback over the coming weeks. Also, any offers of help kindly appreciated. This includes, proof reading, testing on other platforms, standardization and evangelism. Best regards, Mark Bannister. From nobody Sun Dec 14 08:10:50 2014 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F69C1A6FCA for ; Sun, 14 Dec 2014 08:10:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.388 X-Spam-Level: X-Spam-Status: No, score=0.388 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 XAHPuYUzK2Ah for ; Sun, 14 Dec 2014 08:10:47 -0800 (PST) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FED71A6F33 for ; Sun, 14 Dec 2014 08:10:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 2993B60334 for ; Sun, 14 Dec 2014 17:10:43 +0100 (CET) X-Virus-Scanned: amavisd-new at stroeder.com Received: from srv1.stroeder.com ([127.0.0.1]) by localhost (srv1.stroeder.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Naag2XHWgTey for ; Sun, 14 Dec 2014 17:10:39 +0100 (CET) Received: from [10.1.0.2] (unknown [10.1.0.2]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client CN "michael@stroeder.com", Issuer "StartCom Class 1 Primary Intermediate Client CA" (verified OK)) by srv1.stroeder.com (Postfix) with ESMTPS id 90C9D602E4 for ; Sun, 14 Dec 2014 16:10:38 +0000 (UTC) Message-ID: <548DB67C.5060009@stroeder.com> Date: Sun, 14 Dec 2014 17:10:36 +0100 From: =?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1 MIME-Version: 1.0 To: ldapext@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070203080708040506070003" Archived-At: http://mailarchive.ietf.org/arch/msg/ldapext/wBRh4oLEeFZF_xzExo-QEwM5fp0 Subject: [ldapext] why posixAccount MUST contain 'cn'? X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Dec 2014 16:10:49 -0000 This is a cryptographically signed message in MIME format. --------------ms070203080708040506070003 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable HI! Is there any strong reason why auxiliary object class 'posixAccount' has defined 'cn' as being a mandatory attribute? I'd be in favour of relaxing this to MAY cn in RFC2307bis. Also what's the distinction of 'cn' and 'gecos' in 'posixAccount'. It see= ms most NSS LDAP clients use attribute 'cn' as gecos field today. Ciao, Michael. --------------ms070203080708040506070003 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMgTCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGRTCCBS2gAwIBAgIDC01QMA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTQwOTIzMjA0NzU1 WhcNMTUwOTI0MjIwNTE4WjBfMRkwFwYDVQQNExA2TTJZN2k5ekR0ZTZqVXcwMR0wGwYDVQQD DBRtaWNoYWVsQHN0cm9lZGVyLmNvbTEjMCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRl ci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKcgfT19Tn3u/h+Di7CoUk M9TFAdX2rGt8z9ze95K0/JiXQmiuooesP6F8I1n5OjLrk031/287bpaecugMX4UTYORCLrWJ OArmNlOvl0kbVZCSTr3xQ1Y7zuVRYFFhiJQzvALd6TYTSvNH32ojETh0b3DCzX0Xcoom803y 0xPKg/DlWTDirHZJbnhYQEzHugJcEhk88MPyi+V53q8NXB5VJphcVRuTFsolHzsyyKHfgFr5 wzlIAdA1DXWNpImMV6ptCdeN/ScRKe+jRchyRz3DbjTDeNyC7pvlIhAEja+/lNoi/u8qo2TS j5wZz02cLDn/EP84AH0CP+oNxro2F4cJAgMBAAGjggLaMIIC1jAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFOPPUGEQ tk7fMQl+ZlDgj5zo0JciMB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB8GA1Ud EQQYMBaBFG1pY2hhZWxAc3Ryb2VkZXIuY29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEE AYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGlj eS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRo ZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBw b2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBs aWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6Ap oCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEB BIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3Mx L2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMv c3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAB8HJ30IRnmli5Frde4TnF4mgikOiXbYDWYga 5GrFoEUi6aaYOhiv+1WAWh3/d69Ak75p3xPnCmihjjbYeQc3hrVQju6MIpxT8+tBLGa/bwAC yXgWj8idjWdIWMzLxjCPcQb4R2PVmkKTNNE0ZmMFrpSPtRjtRbvWRhxJ0IF7y9z1mLfo6cca RdE5YiKLfAEosMRmrGSfDQKP1NPLmXKWVjPIeS7hpcsM+GJitPOFaLCBibB5ou9b/KphWwdG lby53Oo6vrG9RVy5GZ8xMQ0ztFKVFlXDb7n4j7OfuOo6utQs7UU/sujlw+KWwylIw7Cgmc8t CA1m9c48U7pVoMI5ujGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAwtNUDAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xNDEyMTQxNjEwMzZaMCMGCSqGSIb3DQEJBDEWBBSYhwEKr/4J 3QUhrKt3hxGMeRb5ojBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQME AQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIH MA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQIDC01QMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFy eSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMLTVAwDQYJKoZIhvcNAQEBBQAEggEAg/n5R7Az cDrNkO1ttP+ZsC0LFEO7MMaTHMUcKO281dsleeONnLQEly5RU0kZNZOyY3q/QMx2qjsDZ4E9 XuJeMMTaU1sExr/EJ8ryP54jelPgvw8siu3ZzO92+B6MtycFUVdFV97SXn/oIGsqfck1wlKS GLbPnXUk7+d7Q9/j1Nzf0IQtadx3nuagT9rggnDF7Fs9w2uQ05KzEIH2xDbctnfF4l9lRuoC bI27Uk2GHaPPScn0CA3SsCf2lS9pKQoMqX6GJ9+mpeDRGLYPZCVjK0rLA7WJmaIb8twAwU3e Wg4OK+P0jWffpuaGrXLzLwZv6qq0uqaxYjBm28+0SSUucAAAAAAAAA== --------------ms070203080708040506070003-- From nobody Sun Dec 14 08:43:28 2014 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C963B1A0100 for ; Sun, 14 Dec 2014 08:43:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.71 X-Spam-Level: X-Spam-Status: No, score=-1.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] 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 1TDqDg0InuMJ for ; Sun, 14 Dec 2014 08:43:26 -0800 (PST) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 271031A00F7 for ; Sun, 14 Dec 2014 08:43:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1418575405; d=isode.com; s=selector; i=@isode.com; bh=ZfQsn+lQ92LQgR0ZNCejG5vD5uhSiqvj+kTSGhmpV3c=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=JBrxHxxS1VtGD7dEwLq7efeuKThOe5j1J18TzhLQFWwkhx6T2mXY3k6KWqq+Hk5UbiyfCJ Zxs19smMzdk79hT7t1PMZjCAKLOKZmUr95h2aiO0IYKX2kCmnIT5Pvc/1stbynJGvvaX+X uDecYdBhhjiFhzyKuvYRMvQLzwi2uHI=; Received: from pagan.boolean.net ((unknown) [75.141.217.19]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Sun, 14 Dec 2014 16:43:25 +0000 X-SMTP-Protocol-Errors: NORDNS PIPELINING From: Kurt Zeilenga In-Reply-To: <548DB67C.5060009@stroeder.com> Date: Sun, 14 Dec 2014 08:43:19 -0800 Message-Id: References: <548DB67C.5060009@stroeder.com> To: =?utf-8?Q?Michael_Str=C3=B6der?= X-Mailer: Apple Mail (2.1993) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/ldapext/4ByjK5XzmxLq9gBUGW3Vcwt5IfY Cc: ldapext@ietf.org Subject: Re: [ldapext] why posixAccount MUST contain 'cn'? X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Dec 2014 16:43:27 -0000 >=20 >=20 > I'd be in favour of relaxing this to MAY cn in RFC2307bis. See BCP 118 [RFC 4521], Section 5 concerning IETF rules for changing = previously published schema definitions. From nobody Sun Dec 14 09:35:30 2014 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3781A0118 for ; Sun, 14 Dec 2014 09:35:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 gg-w1sz9EtRX for ; Sun, 14 Dec 2014 09:35:28 -0800 (PST) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E0911A0117 for ; Sun, 14 Dec 2014 09:35:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 2C3CC6033C; Sun, 14 Dec 2014 18:35:24 +0100 (CET) X-Virus-Scanned: amavisd-new at stroeder.com Received: from srv1.stroeder.com ([127.0.0.1]) by localhost (srv1.stroeder.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAvKwZ9Y9_cD; Sun, 14 Dec 2014 18:35:16 +0100 (CET) Received: from [10.1.0.2] (unknown [10.1.0.2]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client CN "michael@stroeder.com", Issuer "StartCom Class 1 Primary Intermediate Client CA" (verified OK)) by srv1.stroeder.com (Postfix) with ESMTPS id 2D3EB602E4; Sun, 14 Dec 2014 17:35:16 +0000 (UTC) Message-ID: <548DCA51.7080002@stroeder.com> Date: Sun, 14 Dec 2014 18:35:13 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1 MIME-Version: 1.0 To: Kurt Zeilenga References: <548DB67C.5060009@stroeder.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010602020900010802090301" Archived-At: http://mailarchive.ietf.org/arch/msg/ldapext/OSr3Q_E79ERgXILaktXSBFCRjqc Cc: ldapext@ietf.org Subject: Re: [ldapext] why posixAccount MUST contain 'cn'? X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Dec 2014 17:35:29 -0000 This is a cryptographically signed message in MIME format. --------------ms010602020900010802090301 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Kurt Zeilenga wrote: >> I'd be in favour of relaxing this to MAY cn in RFC2307bis. >=20 > See BCP 118 [RFC 4521], Section 5 concerning IETF rules for changing pr= eviously published schema definitions. Yes, but RFC2307bis also changes posixGroup schema. Ciao, Michael. --------------ms010602020900010802090301 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMgTCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGRTCCBS2gAwIBAgIDC01QMA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTQwOTIzMjA0NzU1 WhcNMTUwOTI0MjIwNTE4WjBfMRkwFwYDVQQNExA2TTJZN2k5ekR0ZTZqVXcwMR0wGwYDVQQD DBRtaWNoYWVsQHN0cm9lZGVyLmNvbTEjMCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRl ci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKcgfT19Tn3u/h+Di7CoUk M9TFAdX2rGt8z9ze95K0/JiXQmiuooesP6F8I1n5OjLrk031/287bpaecugMX4UTYORCLrWJ OArmNlOvl0kbVZCSTr3xQ1Y7zuVRYFFhiJQzvALd6TYTSvNH32ojETh0b3DCzX0Xcoom803y 0xPKg/DlWTDirHZJbnhYQEzHugJcEhk88MPyi+V53q8NXB5VJphcVRuTFsolHzsyyKHfgFr5 wzlIAdA1DXWNpImMV6ptCdeN/ScRKe+jRchyRz3DbjTDeNyC7pvlIhAEja+/lNoi/u8qo2TS j5wZz02cLDn/EP84AH0CP+oNxro2F4cJAgMBAAGjggLaMIIC1jAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFOPPUGEQ tk7fMQl+ZlDgj5zo0JciMB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB8GA1Ud EQQYMBaBFG1pY2hhZWxAc3Ryb2VkZXIuY29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEE AYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGlj eS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRo ZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBw b2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBs aWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6Ap oCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEB BIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3Mx L2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMv c3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAB8HJ30IRnmli5Frde4TnF4mgikOiXbYDWYga 5GrFoEUi6aaYOhiv+1WAWh3/d69Ak75p3xPnCmihjjbYeQc3hrVQju6MIpxT8+tBLGa/bwAC yXgWj8idjWdIWMzLxjCPcQb4R2PVmkKTNNE0ZmMFrpSPtRjtRbvWRhxJ0IF7y9z1mLfo6cca RdE5YiKLfAEosMRmrGSfDQKP1NPLmXKWVjPIeS7hpcsM+GJitPOFaLCBibB5ou9b/KphWwdG lby53Oo6vrG9RVy5GZ8xMQ0ztFKVFlXDb7n4j7OfuOo6utQs7UU/sujlw+KWwylIw7Cgmc8t CA1m9c48U7pVoMI5ujGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAwtNUDAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xNDEyMTQxNzM1MTNaMCMGCSqGSIb3DQEJBDEWBBS5K8W1fV4Z LtwCaozJjSVSsXKBOjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQME AQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIH MA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQIDC01QMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFy eSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMLTVAwDQYJKoZIhvcNAQEBBQAEggEAN+hVi3LT 34jnv0t+kenCGITGFVsdDizNwJemMas4vKPbXQUUl50jLz61xmXbj3bebd0SGvJF8CySOdEP vFyOICEhHfpDJ0j+27xLCtWtn6Em3y3XQ3tn2gJy+9MezPvBm29FKOFcZQlp0HJR7WM5i1SW 3BnNI8i57KM6IKyWbkE1+7pR+VKTerjKzN6EIUv6fklcF0j+NSxRaklbgRtpmSLlSYzVtYtS z0kdgU4sxJP/6VfNUBU/NJBFds31+mTRLg3jskKo1Sdn3lUHc+AKPyR8mE6OA5gEhj/NE0Yw ghZu6GtMbRu2XJTFM8jmxWFnNNr+oUh1UIwDNHWBiGFsZwAAAAAAAA== --------------ms010602020900010802090301-- From nobody Sun Dec 14 10:50:16 2014 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C85C21A014A for ; Sun, 14 Dec 2014 10:50:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.71 X-Spam-Level: X-Spam-Status: No, score=-1.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] 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 3vxWxQitJeEW for ; Sun, 14 Dec 2014 10:50:13 -0800 (PST) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id AB2C71A0140 for ; Sun, 14 Dec 2014 10:50:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1418583012; d=isode.com; s=selector; i=@isode.com; bh=vAadGc+riNnSeh5hcXnxtA9zyosyphnBAhZ9PH57kho=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=gaRe6sSGT+sQY9UeEOcfiPwkrvjraiplYrTaLxpuyCCK6qiYoLSJ/BI6SOanVbzjd5WDoA 0DQxjovNDdXk/qxvCuF2nUMdcT9uByk0gqmlA+nvXKbg8yN9lP53N60zV+dCwm2QCjxN3n M/16a+6oH/Ae139c6hD7h5pD9axWZ3I=; Received: from pagan.boolean.net ((unknown) [75.141.217.19]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Sun, 14 Dec 2014 18:50:12 +0000 X-SMTP-Protocol-Errors: NORDNS PIPELINING From: Kurt Zeilenga In-Reply-To: <548DCA51.7080002@stroeder.com> Date: Sun, 14 Dec 2014 10:50:07 -0800 Message-Id: <778E83EE-875A-486A-8A98-6DF3C309C292@isode.com> References: <548DB67C.5060009@stroeder.com> <548DCA51.7080002@stroeder.com> To: =?windows-1252?Q?Michael_Str=F6der?= X-Mailer: Apple Mail (2.1993) MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/ldapext/HalHRlIaRlAKm80APLpvZBXAKGA Cc: ldapext@ietf.org, Kurt Zeilenga Subject: Re: [ldapext] why posixAccount MUST contain 'cn'? X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Dec 2014 18:50:15 -0000 > On Dec 14, 2014, at 9:35 AM, Michael Str=F6der = wrote: >=20 > Kurt Zeilenga wrote: >>> I'd be in favour of relaxing this to MAY cn in RFC2307bis. >>=20 >> See BCP 118 [RFC 4521], Section 5 concerning IETF rules for changing = previously published schema definitions. >=20 > Yes, but RFC2307bis also changes posixGroup schema. Don=92t expect I-Ds which violate BCPs to become RFCs. =97 Kurt >=20 > Ciao, Michael. >=20 > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www.ietf.org/mailman/listinfo/ldapext From nobody Sun Dec 14 11:43:36 2014 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59FC61A0167 for ; Sun, 14 Dec 2014 11:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 RuCYloQDBR_8 for ; Sun, 14 Dec 2014 11:43:33 -0800 (PST) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4106C1A0181 for ; Sun, 14 Dec 2014 11:42:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 7E80660336; Sun, 14 Dec 2014 20:42:47 +0100 (CET) X-Virus-Scanned: amavisd-new at stroeder.com Received: from srv1.stroeder.com ([127.0.0.1]) by localhost (srv1.stroeder.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZImDXl_49CE; Sun, 14 Dec 2014 20:42:41 +0100 (CET) Received: from [10.1.0.2] (unknown [10.1.0.2]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client CN "michael@stroeder.com", Issuer "StartCom Class 1 Primary Intermediate Client CA" (verified OK)) by srv1.stroeder.com (Postfix) with ESMTPS id 23532602E8; Sun, 14 Dec 2014 19:42:41 +0000 (UTC) Message-ID: <548DE82E.3010103@stroeder.com> Date: Sun, 14 Dec 2014 20:42:38 +0100 From: =?windows-1252?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1 MIME-Version: 1.0 To: Kurt Zeilenga References: <548DB67C.5060009@stroeder.com> <548DCA51.7080002@stroeder.com> <778E83EE-875A-486A-8A98-6DF3C309C292@isode.com> In-Reply-To: <778E83EE-875A-486A-8A98-6DF3C309C292@isode.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080404000908010104030309" Archived-At: http://mailarchive.ietf.org/arch/msg/ldapext/aGZnaIpJ3NVXbv2-CW4zSRdZfSA Cc: ldapext@ietf.org Subject: Re: [ldapext] why posixAccount MUST contain 'cn'? X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Dec 2014 19:43:35 -0000 This is a cryptographically signed message in MIME format. --------------ms080404000908010104030309 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Kurt Zeilenga wrote: >=20 >> On Dec 14, 2014, at 9:35 AM, Michael Str=F6der = wrote: >> >> Kurt Zeilenga wrote: >>>> I'd be in favour of relaxing this to MAY cn in RFC2307bis. >>> >>> See BCP 118 [RFC 4521], Section 5 concerning IETF rules for changing = previously published schema definitions. >> >> Yes, but RFC2307bis also changes posixGroup schema. >=20 > Don=92t expect I-Ds which violate BCPs to become RFCs. Are you saying that draft-howard-rfc2307bis will never become an RFC beca= use it changes the declaration of 'posixGroup' ('member' instead of 'memberUI= D') defined in the experimental RFC 2307? Ciao, Michael. --------------ms080404000908010104030309 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMgTCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGRTCCBS2gAwIBAgIDC01QMA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTQwOTIzMjA0NzU1 WhcNMTUwOTI0MjIwNTE4WjBfMRkwFwYDVQQNExA2TTJZN2k5ekR0ZTZqVXcwMR0wGwYDVQQD DBRtaWNoYWVsQHN0cm9lZGVyLmNvbTEjMCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRl ci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKcgfT19Tn3u/h+Di7CoUk M9TFAdX2rGt8z9ze95K0/JiXQmiuooesP6F8I1n5OjLrk031/287bpaecugMX4UTYORCLrWJ OArmNlOvl0kbVZCSTr3xQ1Y7zuVRYFFhiJQzvALd6TYTSvNH32ojETh0b3DCzX0Xcoom803y 0xPKg/DlWTDirHZJbnhYQEzHugJcEhk88MPyi+V53q8NXB5VJphcVRuTFsolHzsyyKHfgFr5 wzlIAdA1DXWNpImMV6ptCdeN/ScRKe+jRchyRz3DbjTDeNyC7pvlIhAEja+/lNoi/u8qo2TS j5wZz02cLDn/EP84AH0CP+oNxro2F4cJAgMBAAGjggLaMIIC1jAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFOPPUGEQ tk7fMQl+ZlDgj5zo0JciMB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB8GA1Ud EQQYMBaBFG1pY2hhZWxAc3Ryb2VkZXIuY29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEE AYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGlj eS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRo ZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBw b2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBs aWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6Ap oCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEB BIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3Mx L2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMv c3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAB8HJ30IRnmli5Frde4TnF4mgikOiXbYDWYga 5GrFoEUi6aaYOhiv+1WAWh3/d69Ak75p3xPnCmihjjbYeQc3hrVQju6MIpxT8+tBLGa/bwAC yXgWj8idjWdIWMzLxjCPcQb4R2PVmkKTNNE0ZmMFrpSPtRjtRbvWRhxJ0IF7y9z1mLfo6cca RdE5YiKLfAEosMRmrGSfDQKP1NPLmXKWVjPIeS7hpcsM+GJitPOFaLCBibB5ou9b/KphWwdG lby53Oo6vrG9RVy5GZ8xMQ0ztFKVFlXDb7n4j7OfuOo6utQs7UU/sujlw+KWwylIw7Cgmc8t CA1m9c48U7pVoMI5ujGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAwtNUDAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xNDEyMTQxOTQyMzhaMCMGCSqGSIb3DQEJBDEWBBSeexGhF4iR exyXrEOkpH2MXwzurDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQME AQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIH MA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQIDC01QMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFy eSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMLTVAwDQYJKoZIhvcNAQEBBQAEggEAavk8ZaZL GQXGSy9WTLbg9oLhFsNx72R7dGSIBL2EHquEQJziBkJOE4aMpkxt2AOehHA9P8hVI6s6ByLV ZYtp3Z5FuRJnrlWACCpGK9ocCA09wBOmCUsHainVv9I3uFz2JOnfeO+3B8Ynvi33kvJ2/LnC ATlxTAZmHTQcGypimRdBqriaj594ddooW+uBGpI58r3NjxXmvhV/MWxtWYVwx61HtG530yXD YHrCRXrL7rOA+BTYYbAt/RlYnOIyCFqNTx028ymj9iXghpeGXFNZqavt5r1G/vjKVCfYVC6z nTH/5AymK/6LsSjRlD33OdcXZOlYROZKlMnfEB2d01XGCwAAAAAAAA== --------------ms080404000908010104030309-- From nobody Sun Dec 14 12:05:20 2014 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04D8C1A0183 for ; Sun, 14 Dec 2014 12:05:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.71 X-Spam-Level: X-Spam-Status: No, score=-1.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] 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 GVRhVKHqiFNo for ; Sun, 14 Dec 2014 12:05:18 -0800 (PST) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id DB8A21A017E for ; Sun, 14 Dec 2014 12:05:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1418587516; d=isode.com; s=selector; i=@isode.com; bh=WjlF5pilRbA10Dhuopr+YqiLUyITd/bQwzo/v99e4Uw=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=t6PGTHaWT+28+2aEFedz6TFAHM4v4qM4t8eXlRiaPmIP6VMwfwaLCkK7iJVBi7G69uKGA/ 2qEFKKZGxiOyEGT8nOyKsRcZ4R2/QKRLBl918RHk0CdOra5TAof/fOisp+QtLtWsG1loeu qMunwKjX4BuCDkCZkR1J40y3vL0Rjx8=; Received: from pagan.boolean.net ((unknown) [75.141.217.19]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Sun, 14 Dec 2014 20:05:16 +0000 X-SMTP-Protocol-Errors: NORDNS PIPELINING From: Kurt Zeilenga In-Reply-To: <548DE82E.3010103@stroeder.com> Date: Sun, 14 Dec 2014 12:05:11 -0800 Message-Id: <5C9BE5D8-44CA-4CFC-9D63-36C702391B87@isode.com> References: <548DB67C.5060009@stroeder.com> <548DCA51.7080002@stroeder.com> <778E83EE-875A-486A-8A98-6DF3C309C292@isode.com> <548DE82E.3010103@stroeder.com> To: =?windows-1252?Q?Michael_Str=F6der?= X-Mailer: Apple Mail (2.1993) MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/ldapext/yOquMpXI0PQQ0Gg__cquWDZfUNw Cc: ldapext@ietf.org, Kurt Zeilenga Subject: Re: [ldapext] why posixAccount MUST contain 'cn'? X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Dec 2014 20:05:19 -0000 > On Dec 14, 2014, at 11:42 AM, Michael Str=F6der = wrote: >=20 > Kurt Zeilenga wrote: >>=20 >>> On Dec 14, 2014, at 9:35 AM, Michael Str=F6der = wrote: >>>=20 >>> Kurt Zeilenga wrote: >>>>> I'd be in favour of relaxing this to MAY cn in RFC2307bis. >>>>=20 >>>> See BCP 118 [RFC 4521], Section 5 concerning IETF rules for = changing previously published schema definitions. >>>=20 >>> Yes, but RFC2307bis also changes posixGroup schema. >>=20 >> Don=92t expect I-Ds which violate BCPs to become RFCs. >=20 > Are you saying that draft-howard-rfc2307bis will never become an RFC = because > it changes the declaration of 'posixGroup' ('member' instead of = 'memberUID') > defined in the experimental RFC 2307? I won=92t say =93never=94 as well BCPs themselves are subject today=85 = but I can tell you that I, as the IESG=92s appointed LDAP registries = expert to IANA, have and will reject requests to register LDAP = parameters which purport to modify previously published LDAP schema = definitions. Of course, such actions are appealable. =97 Kurt= From nobody Sun Dec 14 12:06:10 2014 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE2521A0195 for ; Sun, 14 Dec 2014 12:06:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] 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 zcZ8j6AEI8RL for ; Sun, 14 Dec 2014 12:06:07 -0800 (PST) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 8397C1A017E for ; Sun, 14 Dec 2014 12:06:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1418587566; d=isode.com; s=selector; i=@isode.com; bh=y1w2MhMEqfxlPwRvQCKvqg6Nhp6YEBgNn2rq7xpryiE=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=C+JcS2pXLxPdWaXPjvtA48YWPSygcQ6QR6xPd25oiWQfYylgA38xDxhDDkwNEnT9zwyr41 JFtK1LXrB/WO1fJcdA6fhb8iWsWVlS1Bm54FN0FGeBzD9fIR4wdXDCdQViTTRc1LH8ltvp KreZrIfbTBtINyvzFY4F8kUpDyn8Kzc=; Received: from pagan.boolean.net ((unknown) [75.141.217.19]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Sun, 14 Dec 2014 20:06:06 +0000 X-SMTP-Protocol-Errors: NORDNS PIPELINING From: Kurt Zeilenga In-Reply-To: <5C9BE5D8-44CA-4CFC-9D63-36C702391B87@isode.com> Date: Sun, 14 Dec 2014 12:06:04 -0800 Message-Id: References: <548DB67C.5060009@stroeder.com> <548DCA51.7080002@stroeder.com> <778E83EE-875A-486A-8A98-6DF3C309C292@isode.com> <548DE82E.3010103@stroeder.com> <5C9BE5D8-44CA-4CFC-9D63-36C702391B87@isode.com> To: Kurt Zeilenga X-Mailer: Apple Mail (2.1993) MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/ldapext/4FJVU-qH3xLpjwmacyegxCqrWaI Cc: ldapext@ietf.org, =?windows-1252?Q?Michael_Str=F6der?= Subject: Re: [ldapext] why posixAccount MUST contain 'cn'? X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Dec 2014 20:06:09 -0000 > On Dec 14, 2014, at 12:05 PM, Kurt Zeilenga = wrote: >=20 >=20 >> On Dec 14, 2014, at 11:42 AM, Michael Str=F6der = wrote: >>=20 >> Kurt Zeilenga wrote: >>>=20 >>>> On Dec 14, 2014, at 9:35 AM, Michael Str=F6der = wrote: >>>>=20 >>>> Kurt Zeilenga wrote: >>>>>> I'd be in favour of relaxing this to MAY cn in RFC2307bis. >>>>>=20 >>>>> See BCP 118 [RFC 4521], Section 5 concerning IETF rules for = changing previously published schema definitions. >>>>=20 >>>> Yes, but RFC2307bis also changes posixGroup schema. >>>=20 >>> Don=92t expect I-Ds which violate BCPs to become RFCs. >>=20 >> Are you saying that draft-howard-rfc2307bis will never become an RFC = because >> it changes the declaration of 'posixGroup' ('member' instead of = 'memberUID') >> defined in the experimental RFC 2307? >=20 > I won=92t say =93never=94 as well BCPs themselves are subject today=85 = =20 s/today/to change/ > but I can tell you that I, as the IESG=92s appointed LDAP registries = expert to IANA, have and will reject requests to register LDAP = parameters which purport to modify previously published LDAP schema = definitions. Of course, such actions are appealable. >=20 > =97 Kurt > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www.ietf.org/mailman/listinfo/ldapext From nobody Sun Dec 14 12:20:22 2014 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD541A0181 for ; Sun, 14 Dec 2014 12:20:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 y7WmBnZn8v5h for ; Sun, 14 Dec 2014 12:20:05 -0800 (PST) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DDD01A0172 for ; Sun, 14 Dec 2014 12:20:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 5994660349; Sun, 14 Dec 2014 21:20:02 +0100 (CET) X-Virus-Scanned: amavisd-new at stroeder.com Received: from srv1.stroeder.com ([127.0.0.1]) by localhost (srv1.stroeder.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjNLqYVWRaF6; Sun, 14 Dec 2014 21:19:54 +0100 (CET) Received: from [10.1.0.2] (unknown [10.1.0.2]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client CN "michael@stroeder.com", Issuer "StartCom Class 1 Primary Intermediate Client CA" (verified OK)) by srv1.stroeder.com (Postfix) with ESMTPS id 1FB3D602E8; Sun, 14 Dec 2014 20:19:54 +0000 (UTC) Message-ID: <548DF0E9.6080405@stroeder.com> Date: Sun, 14 Dec 2014 21:19:53 +0100 From: =?windows-1252?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1 MIME-Version: 1.0 To: Kurt Zeilenga References: <548DB67C.5060009@stroeder.com> <548DCA51.7080002@stroeder.com> <778E83EE-875A-486A-8A98-6DF3C309C292@isode.com> <548DE82E.3010103@stroeder.com> <5C9BE5D8-44CA-4CFC-9D63-36C702391B87@isode.com> In-Reply-To: <5C9BE5D8-44CA-4CFC-9D63-36C702391B87@isode.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000909070106010105000408" Archived-At: http://mailarchive.ietf.org/arch/msg/ldapext/kNiYyqfJAw_a5NR5CaO5t515_eo Cc: ldapext@ietf.org Subject: Re: [ldapext] why posixAccount MUST contain 'cn'? X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Dec 2014 20:20:14 -0000 This is a cryptographically signed message in MIME format. --------------ms000909070106010105000408 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Kurt Zeilenga wrote: >=20 >> On Dec 14, 2014, at 11:42 AM, Michael Str=F6der = wrote: >> >> Kurt Zeilenga wrote: >>> >>>> On Dec 14, 2014, at 9:35 AM, Michael Str=F6der wrote: >>>> >>>> Kurt Zeilenga wrote: >>>>>> I'd be in favour of relaxing this to MAY cn in RFC2307bis. >>>>> >>>>> See BCP 118 [RFC 4521], Section 5 concerning IETF rules for changin= g previously published schema definitions. >>>> >>>> Yes, but RFC2307bis also changes posixGroup schema. >>> >>> Don=92t expect I-Ds which violate BCPs to become RFCs. >> >> Are you saying that draft-howard-rfc2307bis will never become an RFC b= ecause >> it changes the declaration of 'posixGroup' ('member' instead of 'membe= rUID') >> defined in the experimental RFC 2307? >=20 > I won=92t say =93never=94 as well BCPs themselves are subject today=85 = but I can > tell you that I, as the IESG=92s appointed LDAP registries expert to IA= NA, > have and will reject requests to register LDAP parameters which purport= to > modify previously published LDAP schema definitions. Of course, such > actions are appealable. So RFC2307bis must start over with completely new NAMEs for e.g. posixGroup? (Personally I don't care about assigning a new OID because most LDAP clie= nt implementations don't handle OIDs anyway.) Ciao, Michael. --------------ms000909070106010105000408 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMgTCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGRTCCBS2gAwIBAgIDC01QMA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTQwOTIzMjA0NzU1 WhcNMTUwOTI0MjIwNTE4WjBfMRkwFwYDVQQNExA2TTJZN2k5ekR0ZTZqVXcwMR0wGwYDVQQD DBRtaWNoYWVsQHN0cm9lZGVyLmNvbTEjMCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRl ci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKcgfT19Tn3u/h+Di7CoUk M9TFAdX2rGt8z9ze95K0/JiXQmiuooesP6F8I1n5OjLrk031/287bpaecugMX4UTYORCLrWJ OArmNlOvl0kbVZCSTr3xQ1Y7zuVRYFFhiJQzvALd6TYTSvNH32ojETh0b3DCzX0Xcoom803y 0xPKg/DlWTDirHZJbnhYQEzHugJcEhk88MPyi+V53q8NXB5VJphcVRuTFsolHzsyyKHfgFr5 wzlIAdA1DXWNpImMV6ptCdeN/ScRKe+jRchyRz3DbjTDeNyC7pvlIhAEja+/lNoi/u8qo2TS j5wZz02cLDn/EP84AH0CP+oNxro2F4cJAgMBAAGjggLaMIIC1jAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFOPPUGEQ tk7fMQl+ZlDgj5zo0JciMB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB8GA1Ud EQQYMBaBFG1pY2hhZWxAc3Ryb2VkZXIuY29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEE AYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGlj eS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRo ZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBw b2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBs aWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6Ap oCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEB BIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3Mx L2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMv c3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAB8HJ30IRnmli5Frde4TnF4mgikOiXbYDWYga 5GrFoEUi6aaYOhiv+1WAWh3/d69Ak75p3xPnCmihjjbYeQc3hrVQju6MIpxT8+tBLGa/bwAC yXgWj8idjWdIWMzLxjCPcQb4R2PVmkKTNNE0ZmMFrpSPtRjtRbvWRhxJ0IF7y9z1mLfo6cca RdE5YiKLfAEosMRmrGSfDQKP1NPLmXKWVjPIeS7hpcsM+GJitPOFaLCBibB5ou9b/KphWwdG lby53Oo6vrG9RVy5GZ8xMQ0ztFKVFlXDb7n4j7OfuOo6utQs7UU/sujlw+KWwylIw7Cgmc8t CA1m9c48U7pVoMI5ujGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAwtNUDAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xNDEyMTQyMDE5NTNaMCMGCSqGSIb3DQEJBDEWBBTAQJnVzoPf H9Fq/Sl7WeCNjvz8TTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQME AQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIH MA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQIDC01QMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFy eSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMLTVAwDQYJKoZIhvcNAQEBBQAEggEAZ9A5Bm3v wAKZkHR5UgRjed3J3I58M8FZ2qAQtkEJfPIv5+MLMv6LFIhIfgqjj0mE+WnM1cLjBSnyXpMc cKJJn9W5nm8cx0jgXDjX4mcDMAbtAdxKWWKV+o4+I+E8Xhtgp2Su4DC2OFeKO1IG3LmMtCtl qAJ0u6OR5vi6sEs20gf+33c8ZYu2J6FEmQKfAIOxX3SOjwzj8ykpw7H6dNvAr70Bx60BRaoQ wLHw0uMviVVP3TxhxB7Co8SoQPWRWiFsaJ+Dn1i6KR8fvyfSuErh3SRr0oNsHrPb2UBQ8ZGn q+QmQGReX2WH8jc9eNjKRljJGLHe2UjCE60nI+aIx+/ENgAAAAAAAA== --------------ms000909070106010105000408-- From nobody Sun Dec 14 13:11:11 2014 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A50BE1A01A5 for ; Sun, 14 Dec 2014 13:11:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.71 X-Spam-Level: X-Spam-Status: No, score=-1.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] 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 ZtxSHKyopZ9C for ; Sun, 14 Dec 2014 13:11:08 -0800 (PST) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 79E2B1A0151 for ; Sun, 14 Dec 2014 13:11:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1418591467; d=isode.com; s=selector; i=@isode.com; bh=4nwv62NBBkthGGf+cgcKYNbdeeD3AvdM9VigahW4INs=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=NnHs7G/NUbONG/htdFnjLNEHL5MlEGZk85l/vDP8FzT9X5/SMWotB+HwlFEYflU0HRCnZx i0xBShyBM69xj6142eiD87MtyyfLQ5xScWCcmBuNZg9r21yRmzNSXqGOlni2jFj+gmnsj3 EcG7Qr5CwpaOdIG7uDkhr1BF5rOrYzU=; Received: from pagan.boolean.net ((unknown) [75.141.217.19]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Sun, 14 Dec 2014 21:11:07 +0000 X-SMTP-Protocol-Errors: NORDNS PIPELINING From: Kurt Zeilenga In-Reply-To: <548DF0E9.6080405@stroeder.com> Date: Sun, 14 Dec 2014 13:11:02 -0800 Message-Id: References: <548DB67C.5060009@stroeder.com> <548DCA51.7080002@stroeder.com> <778E83EE-875A-486A-8A98-6DF3C309C292@isode.com> <548DE82E.3010103@stroeder.com> <5C9BE5D8-44CA-4CFC-9D63-36C702391B87@isode.com> <548DF0E9.6080405@stroeder.com> To: =?windows-1252?Q?Michael_Str=F6der?= X-Mailer: Apple Mail (2.1993) MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/ldapext/9gzwLocco22bAxGhqk2uGwIsYV4 Cc: ldapext@ietf.org, Kurt Zeilenga Subject: Re: [ldapext] why posixAccount MUST contain 'cn'? X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Dec 2014 21:11:10 -0000 > On Dec 14, 2014, at 12:19 PM, Michael Str=F6der = wrote: >=20 > Kurt Zeilenga wrote: >>=20 >>> On Dec 14, 2014, at 11:42 AM, Michael Str=F6der = wrote: >>>=20 >>> Kurt Zeilenga wrote: >>>>=20 >>>>> On Dec 14, 2014, at 9:35 AM, Michael Str=F6der = wrote: >>>>>=20 >>>>> Kurt Zeilenga wrote: >>>>>>> I'd be in favour of relaxing this to MAY cn in RFC2307bis. >>>>>>=20 >>>>>> See BCP 118 [RFC 4521], Section 5 concerning IETF rules for = changing previously published schema definitions. >>>>>=20 >>>>> Yes, but RFC2307bis also changes posixGroup schema. >>>>=20 >>>> Don=92t expect I-Ds which violate BCPs to become RFCs. >>>=20 >>> Are you saying that draft-howard-rfc2307bis will never become an RFC = because >>> it changes the declaration of 'posixGroup' ('member' instead of = 'memberUID') >>> defined in the experimental RFC 2307? >>=20 >> I won=92t say =93never=94 as well BCPs themselves are subject today=85 = but I can >> tell you that I, as the IESG=92s appointed LDAP registries expert to = IANA, >> have and will reject requests to register LDAP parameters which = purport to >> modify previously published LDAP schema definitions. Of course, such >> actions are appealable. >=20 > So RFC2307bis must start over with completely new NAMEs > for e.g. posixGroup? Yes, as posixGroup has already been published, if you don=92t want to = use it as published, you need to create a replacement for it=85 and that = replacement has to have a new OID and a new NAME. - Kurt >=20 > (Personally I don't care about assigning a new OID because most LDAP = client > implementations don't handle OIDs anyway.) >=20 > Ciao, Michael. >=20 > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www.ietf.org/mailman/listinfo/ldapext From nobody Sun Dec 14 14:49:52 2014 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF4D1A0334 for ; Sun, 14 Dec 2014 14:49:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 jTPe9bn7OHOW for ; Sun, 14 Dec 2014 14:49:49 -0800 (PST) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D8D31A0217 for ; Sun, 14 Dec 2014 14:49:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 34380602E3; Sun, 14 Dec 2014 23:49:46 +0100 (CET) X-Virus-Scanned: amavisd-new at stroeder.com Received: from srv1.stroeder.com ([127.0.0.1]) by localhost (srv1.stroeder.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZAOvg3nQTjm; Sun, 14 Dec 2014 23:49:38 +0100 (CET) Received: from [10.1.0.2] (unknown [10.1.0.2]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client CN "michael@stroeder.com", Issuer "StartCom Class 1 Primary Intermediate Client CA" (verified OK)) by srv1.stroeder.com (Postfix) with ESMTPS id 3D1706027E; Sun, 14 Dec 2014 22:49:38 +0000 (UTC) Message-ID: <548E13FF.7070103@stroeder.com> Date: Sun, 14 Dec 2014 23:49:35 +0100 From: =?windows-1252?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1 MIME-Version: 1.0 To: Kurt Zeilenga References: <548DB67C.5060009@stroeder.com> <548DCA51.7080002@stroeder.com> <778E83EE-875A-486A-8A98-6DF3C309C292@isode.com> <548DE82E.3010103@stroeder.com> <5C9BE5D8-44CA-4CFC-9D63-36C702391B87@isode.com> <548DF0E9.6080405@stroeder.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090106050105090800000502" Archived-At: http://mailarchive.ietf.org/arch/msg/ldapext/1FHo1Zmevaeed5agUw5P5TYa_cM Cc: ldapext@ietf.org Subject: Re: [ldapext] why posixAccount MUST contain 'cn'? X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Dec 2014 22:49:51 -0000 This is a cryptographically signed message in MIME format. --------------ms090106050105090800000502 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Kurt Zeilenga wrote: >=20 >> On Dec 14, 2014, at 12:19 PM, Michael Str=F6der = wrote: >> >> Kurt Zeilenga wrote: >>> >>>> On Dec 14, 2014, at 11:42 AM, Michael Str=F6der wrote: >>>> >>>> Kurt Zeilenga wrote: >>>>> >>>>>> On Dec 14, 2014, at 9:35 AM, Michael Str=F6der wrote: >>>>>> >>>>>> Kurt Zeilenga wrote: >>>>>>>> I'd be in favour of relaxing this to MAY cn in RFC2307bis. >>>>>>> >>>>>>> See BCP 118 [RFC 4521], Section 5 concerning IETF rules for chang= ing previously published schema definitions. >>>>>> >>>>>> Yes, but RFC2307bis also changes posixGroup schema. >>>>> >>>>> Don=92t expect I-Ds which violate BCPs to become RFCs. >>>> >>>> Are you saying that draft-howard-rfc2307bis will never become an RFC= because >>>> it changes the declaration of 'posixGroup' ('member' instead of 'mem= berUID') >>>> defined in the experimental RFC 2307? >>> >>> I won=92t say =93never=94 as well BCPs themselves are subject today=85= but I can >>> tell you that I, as the IESG=92s appointed LDAP registries expert to = IANA, >>> have and will reject requests to register LDAP parameters which purpo= rt to >>> modify previously published LDAP schema definitions. Of course, such= >>> actions are appealable. >> >> So RFC2307bis must start over with completely new NAMEs >> for e.g. posixGroup? >=20 > Yes, as posixGroup has already been published, if you don=92t want to u= se it > as published, you need to create a replacement for it=85 and that repla= cement > has to have a new OID and a new NAME. Hmm, I respect that decision and thanks for the clear words. But it's clearly a problem with all the existing NSS LDAP client implementations/deployments which already use RFC2307bis posixGroup>membe= r draft schema. So the question is: How to correctly push that forward? Some more nitpicking: The RFC 2307 defined OIDs are not listed here only the base OID: http://www.iana.org/assignments/ldap-parameters/ldap-parameters.xhtml Ciao, Michael. --------------ms090106050105090800000502 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMgTCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGRTCCBS2gAwIBAgIDC01QMA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTQwOTIzMjA0NzU1 WhcNMTUwOTI0MjIwNTE4WjBfMRkwFwYDVQQNExA2TTJZN2k5ekR0ZTZqVXcwMR0wGwYDVQQD DBRtaWNoYWVsQHN0cm9lZGVyLmNvbTEjMCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRl ci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKcgfT19Tn3u/h+Di7CoUk M9TFAdX2rGt8z9ze95K0/JiXQmiuooesP6F8I1n5OjLrk031/287bpaecugMX4UTYORCLrWJ OArmNlOvl0kbVZCSTr3xQ1Y7zuVRYFFhiJQzvALd6TYTSvNH32ojETh0b3DCzX0Xcoom803y 0xPKg/DlWTDirHZJbnhYQEzHugJcEhk88MPyi+V53q8NXB5VJphcVRuTFsolHzsyyKHfgFr5 wzlIAdA1DXWNpImMV6ptCdeN/ScRKe+jRchyRz3DbjTDeNyC7pvlIhAEja+/lNoi/u8qo2TS j5wZz02cLDn/EP84AH0CP+oNxro2F4cJAgMBAAGjggLaMIIC1jAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFOPPUGEQ tk7fMQl+ZlDgj5zo0JciMB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB8GA1Ud EQQYMBaBFG1pY2hhZWxAc3Ryb2VkZXIuY29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEE AYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGlj eS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRo ZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBw b2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBs aWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6Ap oCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEB BIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3Mx L2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMv c3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAB8HJ30IRnmli5Frde4TnF4mgikOiXbYDWYga 5GrFoEUi6aaYOhiv+1WAWh3/d69Ak75p3xPnCmihjjbYeQc3hrVQju6MIpxT8+tBLGa/bwAC yXgWj8idjWdIWMzLxjCPcQb4R2PVmkKTNNE0ZmMFrpSPtRjtRbvWRhxJ0IF7y9z1mLfo6cca RdE5YiKLfAEosMRmrGSfDQKP1NPLmXKWVjPIeS7hpcsM+GJitPOFaLCBibB5ou9b/KphWwdG lby53Oo6vrG9RVy5GZ8xMQ0ztFKVFlXDb7n4j7OfuOo6utQs7UU/sujlw+KWwylIw7Cgmc8t CA1m9c48U7pVoMI5ujGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAwtNUDAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xNDEyMTQyMjQ5MzVaMCMGCSqGSIb3DQEJBDEWBBTLzQOl4Gm1 fXIhTFboO3ef3TEqjDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQME AQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIH MA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQIDC01QMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFy eSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMLTVAwDQYJKoZIhvcNAQEBBQAEggEAv+Q3/3J/ DGFsFuNPbOtoTCczlUl7AlxG6Jb7W6vT7BDuGPpdhThk8ORvQfh7kdj9URCr5ODSBGdLgCjS VSqPenV+RmN3JlJK7NIN5T//bbzHBMaVhmYF9Jv5cvBk60BXA3V7DkzPYNCnsby5A3i9FK9+ Mf+Xc1UP2F2Xcd23GW8+VGnTehvHo4nbDheKaYAy9NiEI3lEYfcNhrOvd5VpARlyMAKxEhgq v7DV4rpFQCrPqNHBEtWZTp2TNnPuwyKURbteNHlk+0G/WZnfENQPfbntWQDKTX1rAwFtNjjI kAyQWmQu7L6txS7Ef408rw1Jpq3Hxoix9y12RA+otQPyZQAAAAAAAA== --------------ms090106050105090800000502-- From nobody Sun Dec 14 16:17:40 2014 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 388ED1A024E for ; Sun, 14 Dec 2014 16:17:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] 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 xsck6wHdYZJf for ; Sun, 14 Dec 2014 16:17:37 -0800 (PST) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99FAB1A0217 for ; Sun, 14 Dec 2014 16:17:37 -0800 (PST) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Y0JLz-0006u6-0t; Mon, 15 Dec 2014 01:17:35 +0100 Received: from c162dbf51.dhcp.as2116.net ([81.191.45.22] helo=mysil.uio.no) by mail-mx1.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) user hbf (Exim 4.80) (envelope-from ) id 1Y0JLy-00070q-Iw; Mon, 15 Dec 2014 01:17:34 +0100 Message-ID: <548E2898.7020808@usit.uio.no> Date: Mon, 15 Dec 2014 01:17:28 +0100 From: Hallvard Breien Furuseth User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: =?windows-1252?Q?Michael_Str=F6der?= References: <548DB67C.5060009@stroeder.com> In-Reply-To: <548DB67C.5060009@stroeder.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 4 sum msgs/h 2 total rcpts 1500 max rcpts/h 16 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 7CC13249DB7F34650E3031031FA0A9B007F646EF X-UiO-SPAM-Test: remote_host: 81.191.45.22 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 69 max/h 5 blacklist 0 greylist 0 ratelimit 0 X-UiOonly: 0B4DA9FFBC4FB39794ED1BA2158214D1EC42D1FA Archived-At: http://mailarchive.ietf.org/arch/msg/ldapext/k1I_wz2H8bLTBbEj5rfFpierYo8 Cc: ldapext@ietf.org Subject: Re: [ldapext] why posixAccount MUST contain 'cn'? X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 00:17:39 -0000 On 14/12/14 17:10, Michael Strder wrote: > (...) > Also what's the distinction of 'cn' and 'gecos' in 'posixAccount'. It seems > most NSS LDAP clients use attribute 'cn' as gecos field today. cn is UTF-8. The gecos attribute is IA5 String - i.e. ASCII. One of many ways rfc2307 does not fit the real world too well. memberUid is another IA5 too, both it and uid are case-insensitive even though rfc2307 is for case-sensitive Unix, etc. From nobody Mon Dec 15 04:03:32 2014 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 962A31A1B1A for ; Mon, 15 Dec 2014 04:03:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.671 X-Spam-Level: X-Spam-Status: No, score=0.671 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] 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 0Ck-HCEPjI2u for ; Mon, 15 Dec 2014 04:03:28 -0800 (PST) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 337A71A1B4F for ; Mon, 15 Dec 2014 04:03:27 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id rp18so10656928iec.39 for ; Mon, 15 Dec 2014 04:03:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:cc:content-type; bh=PGOz3tb6JdtftfWdzkBBKzxKWlRgKwh7pYoNL3Xmi1E=; b=dzu/uJrYlEV0MLu7OUYkr4TawJt1rr8021BD/4qaomUV6z7ZUDXVl3sYZXQUEMvSvX VkgCdk3nBi7BkWPq/d1pz+HqUjdYsbeMpXWYFTS9oBxW1xiY+jqLdohrIn1orB6eiotz kDhgI/Hb5MzfjA2ay75ONbOMV8MEIfdbr3t5Dtsx0RXjprEutgZtd6WICZEg/HEtW1vB LiHhw7ZLXRxS2eSvMQiTZTgoIs7qzg045xtxQcF0ftvmQ4LIQlEzdekEJAR2h6zQ8ElS /qy4MxVSNFOU87/6lFmWZ0f+6m0m7fgCq9DtasbPqnb4W+Cwf5GaZ8LBd8onFNEWaeDu cN3Q== X-Gm-Message-State: ALoCoQkh9Loie4/ujk9h+Av0wiNq1Q1uCL/FZadinhnp2XG9XjS341b21fj8OAIYCDEH1azCFA5c X-Received: by 10.50.30.33 with SMTP id p1mr17510644igh.22.1418645006339; Mon, 15 Dec 2014 04:03:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.24.162 with HTTP; Mon, 15 Dec 2014 04:03:06 -0800 (PST) In-Reply-To: <548E2898.7020808@usit.uio.no> References: <548DB67C.5060009@stroeder.com> <548E2898.7020808@usit.uio.no> From: Jim Willeke Date: Mon, 15 Dec 2014 07:03:06 -0500 Message-ID: Cc: ldapext Content-Type: multipart/alternative; boundary=047d7bd75f04aa6c58050a40078b Archived-At: http://mailarchive.ietf.org/arch/msg/ldapext/qLdPkaNWWMhwxO611p8fo9EZSI4 Subject: Re: [ldapext] why posixAccount MUST contain 'cn'? X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 12:03:30 -0000 --047d7bd75f04aa6c58050a40078b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable And then there is also... http://technicalprose.blogspot.co.uk/2013/08/introducing-dbis.html =E1=90=A7 -- -jim Jim Willeke On Sun, Dec 14, 2014 at 7:17 PM, Hallvard Breien Furuseth < h.b.furuseth@usit.uio.no> wrote: > > On 14/12/14 17:10, Michael Str=C3=B6der wrote: > >> (...) >> Also what's the distinction of 'cn' and 'gecos' in 'posixAccount'. It >> seems >> most NSS LDAP clients use attribute 'cn' as gecos field today. >> > > cn is UTF-8. The gecos attribute is IA5 String - i.e. ASCII. > One of many ways rfc2307 does not fit the real world too well. > memberUid is another IA5 too, both it and uid are case-insensitive > even though rfc2307 is for case-sensitive Unix, etc. > > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www.ietf.org/mailman/listinfo/ldapext > --047d7bd75f04aa6c58050a40078b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

--
-jim
Jim Willeke

On Sun, Dec 14, 2014 at 7:17 PM, Hallvard Br= eien Furuseth <h.b.furuseth@usit.uio.no> wrote:On 14/12/14 17:10, Michael Str=C3=B6der wrote:
(...)
Also what's the distinction of 'cn' and 'gecos' in '= ;posixAccount'. It seems
most NSS LDAP clients use attribute 'cn' as gecos field today.

cn is UTF-8.=C2=A0 The gecos attribute is IA5 String - i.e. ASCII.
One of many ways rfc2307 does not fit the real world too well.
memberUid is another IA5 too, both it and uid are case-insensitive
even though rfc2307 is for case-sensitive Unix, etc.
<= div class=3D"h5">

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org<= br> https://www.ietf.org/mailman/listinfo/ldapext
--047d7bd75f04aa6c58050a40078b-- From nobody Mon Dec 15 14:04:50 2014 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3701A00CF for ; Mon, 15 Dec 2014 14:04:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 9daSjeRgbKgX for ; Mon, 15 Dec 2014 14:04:44 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 6A96B1A008C for ; Mon, 15 Dec 2014 14:04:44 -0800 (PST) Received: from host31-49-172-136.range31-49.btcentralplus.com ([31.49.172.136] helo=[192.168.1.67]) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1Y0dkv-00032d-3y; Mon, 15 Dec 2014 22:04:43 +0000 Message-ID: <548F5AE8.4050701@proseconsulting.co.uk> Date: Mon, 15 Dec 2014 22:04:24 +0000 From: Mark R Bannister User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Jim Willeke , =?ISO-8859-1?Q?Michael_Str=F6der?= , kurt.zeilenga@isode.com References: <548DB67C.5060009@stroeder.com> <548E2898.7020808@usit.uio.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030103040409010806070803" X-Mailcore-Auth: 12040446 X-Mailcore-Domain: 1286164 Archived-At: http://mailarchive.ietf.org/arch/msg/ldapext/c_oXDBlhXdVeHz2EPH4mpI0qHDU Cc: ldapext Subject: Re: [ldapext] why posixAccount MUST contain 'cn'? X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 22:04:48 -0000 This is a multi-part message in MIME format. --------------030103040409010806070803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 15/12/2014 12:03, Jim Willeke wrote: > And then there is also... > http://technicalprose.blogspot.co.uk/2013/08/introducing-dbis.html > ? > > -- > -jim > Jim Willeke > > On Sun, Dec 14, 2014 at 7:17 PM, Hallvard Breien Furuseth > > wrote: > > On 14/12/14 17:10, Michael Strder wrote: > > (...) > Also what's the distinction of 'cn' and 'gecos' in > 'posixAccount'. It seems > most NSS LDAP clients use attribute 'cn' as gecos field today. > > > cn is UTF-8. The gecos attribute is IA5 String - i.e. ASCII. > One of many ways rfc2307 does not fit the real world too well. > memberUid is another IA5 too, both it and uid are case-insensitive > even though rfc2307 is for case-sensitive Unix, etc. > > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www.ietf.org/mailman/listinfo/ldapext > > > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www.ietf.org/mailman/listinfo/ldapext Indeed, as Jim pointed out, I have been working on a replacement for RFC2307 and RFC2307bis in my spare time for over 18 months now. I first released some new IETF drafts in August last year, and I've just published the first working reference implementation this month. Kurt - as LDAP registries expert would you help to shepherd these internet drafts through the IANA publication process, as I'm not sure what my next step should be now? In DBIS I have fixed the case insensitivity issues that were present in RFC2307, and I believe it is compliant with BCP 118 [RFC 4521] section 5 as I use new names and OIDs for any attributes or object classes that I needed to change. I've introduced 'posixUserAccount' to replace 'posixAccount' which does not use 'cn', the gecos field can be set to point to any attribute you like, I've introduced 'posixGroupAccount' to replace 'posixGroup', as well as a host of other improvements. The drafts are: draft-bannister-dbis-mapping (DBIS Mapping Objects) draft-bannister-dbis-netgroup (DBIS Netgroups and Netservices) draft-bannister-dbis-passwd (DBIS Users and Groups) draft-bannister-dbis-hosts (DBIS Hosts, Networks and Services) draft-bannister-dbis-devices (DBIS Devices) draft-bannister-dbis-automounter (DBIS Automounter) draft-bannister-dbis-custom (DBIS Custom Maps) The intention is for these to obsolete RFC2307 and RFC2307bis. Also of interest: * DBIS Reference Implementation on SourceForge (dbis.sf.net) * Three articles about DBIS from last year on my blog (technicalprose.blogspot.co.uk) The reference implementation works fine with Python 2.7 (tested on OpenSuSE 12.x), and I hope to get it working on Python 2.6 this week or next (for RHEL 6 and Solaris 11 users). Best regards, Mark. --------------030103040409010806070803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 15/12/2014 12:03, Jim Willeke wrote:

--
-jim
Jim Willeke

On Sun, Dec 14, 2014 at 7:17 PM, Hallvard Breien Furuseth <h.b.furuseth@usit.uio.no> wrote:
On 14/12/14 17:10, Michael Ströder wrote:
(...)
Also what's the distinction of 'cn' and 'gecos' in 'posixAccount'. It seems
most NSS LDAP clients use attribute 'cn' as gecos field today.

cn is UTF-8.  The gecos attribute is IA5 String - i.e. ASCII.
One of many ways rfc2307 does not fit the real world too well.
memberUid is another IA5 too, both it and uid are case-insensitive
even though rfc2307 is for case-sensitive Unix, etc.


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext

Indeed, as Jim pointed out, I have been working on a replacement for RFC2307 and RFC2307bis in my
spare time for over 18 months now.  I first released some new IETF drafts in August last year, and I've
just published the first working reference implementation this month.

Kurt - as LDAP registries expert would you help to shepherd these internet drafts through the IANA
publication process, as I'm not sure what my next step should be now?

In DBIS I have fixed the case insensitivity issues that were present in RFC2307, and I believe it is compliant
with BCP 118 [RFC 4521] section 5 as I use new names and OIDs for any attributes or object classes
that I needed to change.  I've introduced 'posixUserAccount' to replace 'posixAccount' which does not
use 'cn', the gecos field can be set to point to any attribute you like, I've introduced 'posixGroupAccount'
to replace 'posixGroup', as well as a host of other improvements.

The drafts are:

draft-bannister-dbis-mapping (DBIS Mapping Objects)
draft-bannister-dbis-netgroup (DBIS Netgroups and Netservices)
draft-bannister-dbis-passwd (DBIS Users and Groups)
draft-bannister-dbis-hosts (DBIS Hosts, Networks and Services)
draft-bannister-dbis-devices (DBIS Devices)
draft-bannister-dbis-automounter (DBIS Automounter)
draft-bannister-dbis-custom (DBIS Custom Maps)

The intention is for these to obsolete RFC2307 and RFC2307bis.

Also of interest:

   * DBIS Reference Implementation on SourceForge (dbis.sf.net)
   * Three articles about DBIS from last year on my blog (technicalprose.blogspot.co.uk)

The reference implementation works fine with Python 2.7 (tested on OpenSuSE 12.x), and I hope
to get it working on Python 2.6 this week or next (for RHEL 6 and Solaris 11 users).

Best regards,
Mark.

--------------030103040409010806070803-- From nobody Tue Dec 16 09:50:49 2014 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 546E71A7026 for ; Tue, 16 Dec 2014 09:50:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1 X-Spam-Level: * X-Spam-Status: No, score=1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] 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 gpzGmWJU4sbw for ; Tue, 16 Dec 2014 09:50:47 -0800 (PST) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F2291A7023 for ; Tue, 16 Dec 2014 09:50:46 -0800 (PST) Received: by mail-lb0-f179.google.com with SMTP id z11so11282856lbi.10 for ; Tue, 16 Dec 2014 09:50:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=FdaFy4fQMUzyrv5JkjIpOglqF2ftaVpnvE7wvwkBtOs=; b=R4w3rF/o2FRJFjJDmTPLjg7mpLl4M7sM2x90gXbZbM0TIRnzlB3w1IrXGRH92vXe0g ufxyegHWwlH/gRETKym1Y9ZFFuBdhu9YuB7rQBfX+1z/MN0P5XhlyyrERfKa7W0SvU/R iLufoVP8IIPAVlNxrk7oTFDvA5pVYJVDE3naT4aIcXMhByRrDImk6n4/QlPiw5HhcBIn jLv8cznSyVUmhbSUHVYGvqeBhVVZ2JnUCLLrdr2Tvt4E/PXIGpMM0n1o0QbkIvB/CbB+ VEac9Qx8xhbKMoEvtFo1uq7FPRtqkZf3OlulxEtrdVd6jC4TRSzCn5VBLD/8aRFsb+iK pCOg== MIME-Version: 1.0 X-Received: by 10.152.44.167 with SMTP id f7mr37353399lam.30.1418752245048; Tue, 16 Dec 2014 09:50:45 -0800 (PST) Received: by 10.112.95.20 with HTTP; Tue, 16 Dec 2014 09:50:44 -0800 (PST) In-Reply-To: <548DB67C.5060009@stroeder.com> References: <548DB67C.5060009@stroeder.com> Date: Tue, 16 Dec 2014 12:50:44 -0500 Message-ID: From: Charlie To: =?UTF-8?Q?Michael_Str=C3=B6der?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/ldapext/fprff_GR64-Y1mLGrVz0aptMDHE Cc: ldapext Subject: Re: [ldapext] why posixAccount MUST contain 'cn'? X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 17:50:48 -0000 Michael asked, "Also what's the distinction of 'cn' and 'gecos' in 'posixAccount'? It seems most NSS LDAP clients use attribute 'cn' as gecos field today." CN stands for Common Name. GECOS stands for General Electric Comprehensive Operating Supervisor. The GECOS field in POSIX was created to hold non-unix attributes required by the GE COS operating system, because Denis Ritchie and Ken Thompson could not afford a printer, and had to print through a GCOS system, which required user attributes Unix does not use. Those attributes were stuffed into the GECOS field. Today the GECOS field is subfielded, holding multiple data items, which might include the common name associated with the user of a POSIX account, as well as things like office location, extension, and home phone. Tools like finger, chfn and adduser expect subfields within the GECOS field, separated by commas. I have never seen an LDAP implementation where GECOS and CN were synonymous. But the world's a big place, I guess! When we create or modify a user account, we maintain the same data in the appropriate GECOS subfields as we do in attributes like l and homeTelephoneNumber. This gives us broad compatibility across OSes and tools. Sorry about the late answer... --Charlie On Sun, Dec 14, 2014 at 11:10 AM, Michael Str=C3=B6der wrote: > HI! > > Is there any strong reason why auxiliary object class 'posixAccount' has > defined 'cn' as being a mandatory attribute? > > I'd be in favour of relaxing this to MAY cn in RFC2307bis. > > Also what's the distinction of 'cn' and 'gecos' in 'posixAccount'. It see= ms > most NSS LDAP clients use attribute 'cn' as gecos field today. > > Ciao, Michael. > > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www.ietf.org/mailman/listinfo/ldapext > From nobody Tue Dec 16 10:10:26 2014 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0341A86DF for ; Tue, 16 Dec 2014 10:10:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.609 X-Spam-Level: X-Spam-Status: No, score=-0.609 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] 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 sgodEMeR8PJt for ; Tue, 16 Dec 2014 10:10:20 -0800 (PST) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 3CBF11A7028 for ; Tue, 16 Dec 2014 10:10:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1418753414; d=isode.com; s=selector; i=@isode.com; bh=gt4dr4/9QzjHZc9JNIfaNvEut62Bra4J7oIrasJkaCQ=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=gr1fRw5ICbL1AK8pHvJUjCNgPil9CGSHvOUV7y4wzmyC1BvR134RIv9HBq9T8EbtlheyCG XnUS0Ya5q8eYdF4n6N9fbHuexpWhhOmknrq11wl2FoImgo6SBCo1RT+tqureYsdx3sKosz 9nBACSEpm72yJqDhQ/AUINB+2pgshrM=; Received: from pagan.boolean.net ((unknown) [75.141.217.19]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 16 Dec 2014 18:10:13 +0000 X-SMTP-Protocol-Errors: NORDNS PIPELINING From: Kurt Zeilenga In-Reply-To: <548F5AE8.4050701@proseconsulting.co.uk> Date: Tue, 16 Dec 2014 10:09:53 -0800 Message-Id: <7001CBE1-8A2C-47CF-81A2-58F0CA403CA0@isode.com> References: <548DB67C.5060009@stroeder.com> <548E2898.7020808@usit.uio.no> <548F5AE8.4050701@proseconsulting.co.uk> To: Mark R Bannister X-Mailer: Apple Mail (2.1993) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="Apple-Mail=_E965BF33-CCE5-4E2F-A46F-CC2B22626A0E" Archived-At: http://mailarchive.ietf.org/arch/msg/ldapext/UxdXuKLZhavljQRIiFeNi8SoUP4 Cc: ldapext , Kurt Zeilenga , =?utf-8?Q?Michael_Str=C3=B6der?= , Jim Willeke Subject: Re: [ldapext] why posixAccount MUST contain 'cn'? X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 18:10:24 -0000 --Apple-Mail=_E965BF33-CCE5-4E2F-A46F-CC2B22626A0E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Dec 15, 2014, at 2:04 PM, Mark R Bannister = wrote: >=20 > On 15/12/2014 12:03, Jim Willeke wrote: >> And then there is also... >> http://technicalprose.blogspot.co.uk/2013/08/introducing-dbis.html = >> =E1=90=A7 >>=20 >> -- >> -jim >> Jim Willeke >>=20 >> On Sun, Dec 14, 2014 at 7:17 PM, Hallvard Breien Furuseth = > wrote: >> On 14/12/14 17:10, Michael Str=C3=B6der wrote: >> (...) >> Also what's the distinction of 'cn' and 'gecos' in 'posixAccount'. It = seems >> most NSS LDAP clients use attribute 'cn' as gecos field today. >>=20 >> cn is UTF-8. The gecos attribute is IA5 String - i.e. ASCII. >> One of many ways rfc2307 does not fit the real world too well. >> memberUid is another IA5 too, both it and uid are case-insensitive >> even though rfc2307 is for case-sensitive Unix, etc. >>=20 >>=20 >> _______________________________________________ >> Ldapext mailing list >> Ldapext@ietf.org >> https://www.ietf.org/mailman/listinfo/ldapext = >>=20 >>=20 >> _______________________________________________ >> Ldapext mailing list >> Ldapext@ietf.org >> https://www.ietf.org/mailman/listinfo/ldapext = >=20 > Indeed, as Jim pointed out, I have been working on a replacement for = RFC2307 and RFC2307bis in my > spare time for over 18 months now. I first released some new IETF = drafts in August last year, and I've > just published the first working reference implementation this month. >=20 > Kurt - as LDAP registries expert would you help to shepherd these = internet drafts through the IANA > publication process, as I'm not sure what my next step should be now? Mark, As far as next steps, depends on whether you intend to pursue = publication through the IETF or through the Independent Submission = Editor (ISE). The former is appropriate for all standard track document = or any non-standard track document for which you want to publish = community consensus. If however you want to publish your own personal = views, then ISE is more appropriate. If the latter, the next step would be to submit the I-Ds to the ISE. The = process is roughly outlined at >. If the former, the next step would be to contact an App Area AD = > and ask for = guidance. Lastly, I note that intend to continue reducing my IETF activities = around LDAP as I no longer work day-to-day with LDAP. So I=E2=80=99m = saying =E2=80=9Cno=E2=80=9D to requests to get involved beyond my = current very limited role as the LDAP registries expert. =E2=80=94 Kurt >=20 > In DBIS I have fixed the case insensitivity issues that were present = in RFC2307, and I believe it is compliant > with BCP 118 [RFC 4521] section 5 as I use new names and OIDs for any = attributes or object classes > that I needed to change. I've introduced 'posixUserAccount' to = replace 'posixAccount' which does not > use 'cn', the gecos field can be set to point to any attribute you = like, I've introduced 'posixGroupAccount' > to replace 'posixGroup', as well as a host of other improvements. >=20 > The drafts are: >=20 > draft-bannister-dbis-mapping = (DBIS Mapping = Objects) > draft-bannister-dbis-netgroup = (DBIS = Netgroups and Netservices) > draft-bannister-dbis-passwd = (DBIS Users and = Groups) > draft-bannister-dbis-hosts = (DBIS Hosts, = Networks and Services) > draft-bannister-dbis-devices = (DBIS Devices) > draft-bannister-dbis-automounter = (DBIS = Automounter) > draft-bannister-dbis-custom = (DBIS Custom = Maps) >=20 > The intention is for these to obsolete RFC2307 and RFC2307bis. >=20 > Also of interest: >=20 > * DBIS Reference Implementation on SourceForge = (dbis.sf.net) > * Three articles about DBIS from last year on my blog = = (technicalprose.blogspot.co.uk) >=20 > The reference implementation works fine with Python 2.7 (tested on = OpenSuSE 12.x), and I hope > to get it working on Python 2.6 this week or next (for RHEL 6 and = Solaris 11 users). >=20 > Best regards, > Mark. >=20 > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www.ietf.org/mailman/listinfo/ldapext --Apple-Mail=_E965BF33-CCE5-4E2F-A46F-CC2B22626A0E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Dec 15, 2014, at 2:04 PM, Mark R Bannister <dbis@proseconsulting.co.uk> wrote:

=20 =20
On 15/12/2014 12:03, Jim Willeke wrote:
And then there is also...
http://technicalprose.blogspot.co.uk/2013/08/introducing-dbis.h= tml
=E1=90=A7

--
-jim
Jim Willeke

On Sun, Dec 14, 2014 at 7:17 PM, Hallvard Breien Furuseth <h.b.furuseth@usit.uio.no> wrote:
On 14/12/14 17:10, Michael Str=C3=B6der wrote:
(...)
Also what's the distinction of 'cn' and 'gecos' in 'posixAccount'. It seems
most NSS LDAP clients use attribute 'cn' as gecos field today.

cn is UTF-8.  The gecos attribute is IA5 String - i.e. ASCII.
One of many ways rfc2307 does not fit the real world too well.
memberUid is another IA5 too, both it and uid are case-insensitive
even though rfc2307 is for case-sensitive Unix, etc.


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.or=
g/mailman/listinfo/ldapext

Indeed, as Jim pointed out, I have been working on a replacement for RFC2307 and RFC2307bis in my
spare time for over 18 months now.  I first released some new = IETF drafts in August last year, and I've
just published the first working reference implementation this month.

Kurt - as LDAP registries expert would you help to shepherd these internet drafts through the IANA
publication process, as I'm not sure what my next step should be now?

Mark,

As far as = next steps, depends on whether you intend to pursue publication through = the IETF or through the Independent Submission Editor (ISE).  The = former is appropriate for all standard track document or any = non-standard track document for which you want to publish community = consensus.  If however you want to publish your own personal views, = then ISE is more appropriate.

If the = latter, the next step would be to submit the I-Ds to the ISE. The = process is roughly outlined at <https://www.rfc-editor.org/indsubs.html>.

If the former, the next step would be to contact = an App Area AD <app-ads@tools.ietf.org> and ask for = guidance.

Lastly, I note that intend = to continue reducing my IETF activities around LDAP as I no longer work = day-to-day with LDAP.  So I=E2=80=99m saying =E2=80=9Cno=E2=80=9D = to requests to get involved beyond my current very limited role as the = LDAP registries expert.

=E2=80=94 = Kurt



In DBIS I have fixed the case insensitivity issues that were present in RFC2307, and I believe it is compliant
with BCP 118 [RFC 4521] section 5 as I use new names and OIDs for any attributes or object classes
that I needed to change.  I've introduced 'posixUserAccount' to replace 'posixAccount' which does not
use 'cn', the gecos field can be set to point to any attribute you like, I've introduced 'posixGroupAccount'
to replace 'posixGroup', as well as a host of other improvements.

The drafts are:

draft-bannister-dbis-mapping (DBIS Mapping Objects)
draft-bannister-dbis-netgroup (DBIS Netgroups and Netservices)
draft-bannister-dbis-passwd (DBIS Users and Groups)
draft-bannister-dbis-hosts (DBIS Hosts, Networks and Services)
draft-bannister-dbis-devices (DBIS Devices)
draft-bannister-dbis-automounter (DBIS Automounter)
draft-bannister-dbis-custom (DBIS Custom Maps)

The intention is for these to obsolete RFC2307 and RFC2307bis.

Also of interest:

   * DBIS = Reference Implementation on SourceForge (dbis.sf.net)
   * Three articles about DBIS from last year on my blog (technicalprose.blogspot.co.uk)

The reference implementation works fine with Python 2.7 (tested on OpenSuSE 12.x), and I hope
to get it working on Python 2.6 this week or next (for RHEL 6 and Solaris 11 users).

Best regards,
Mark.

_______________________________________________
Ldapext = mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext

= --Apple-Mail=_E965BF33-CCE5-4E2F-A46F-CC2B22626A0E-- From nobody Tue Dec 16 14:12:07 2014 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 757681A8871 for ; Tue, 16 Dec 2014 14:12:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.548 X-Spam-Level: X-Spam-Status: No, score=0.548 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] 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 yUVFKeDxKfoB for ; Tue, 16 Dec 2014 14:12:01 -0800 (PST) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::8]) (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 E28071A87DE for ; Tue, 16 Dec 2014 14:11:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418767904; l=7498; s=domk; d=stroeder.com; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From: Date; bh=zdLn7ElgLsjzXVUz7y7Mhq8dtgs=; b=J9pgSYXG7BKsI95nrB1J+TUV5ghIEiFahp1Bf2NkkPhsO5ifsGX9YoIvbVzVClRL76f OGfRZRU0rdRTf9TW39zUt7ro3u/jEtzmJW8ekgPOWWAKariTt/KEsAgjGn+fIxBzVrQt6 ZnYniIHGJx680UhDdG4tNFo/+XQeLDifbDs= X-RZG-AUTH: :IWUHfUGtd9+vE/nIU31usF8LLMefsb7+CgbCKRTRv1L3o9ypgEohmN2qrwj+HA== X-RZG-CLASS-ID: mo00 Received: from [10.1.1.5] (p4FDB6BDB.dip0.t-ipconnect.de [79.219.107.219]) by smtp.strato.de (RZmta 36.3 DYNA|AUTH) with ESMTPSA id Y03b67qBGMBhycV (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "SuperAdmin", Issuer "Interims-CA" (verification FAILED - unable to verify the first certificate)) (Client hostname not verified); Tue, 16 Dec 2014 23:11:43 +0100 (CET) Message-ID: <5490AE1C.6010004@stroeder.com> Date: Tue, 16 Dec 2014 23:11:40 +0100 From: =?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1 MIME-Version: 1.0 To: Charlie References: <548DB67C.5060009@stroeder.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050500030301000001050600" Archived-At: http://mailarchive.ietf.org/arch/msg/ldapext/gUv4ZOO2DuJutENfSbQ9kBdHESk Cc: ldapext Subject: Re: [ldapext] why posixAccount MUST contain 'cn'? X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 22:12:03 -0000 This is a cryptographically signed message in MIME format. --------------ms050500030301000001050600 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Charlie, Charlie wrote: > Michael asked, "Also what's the distinction of 'cn' and 'gecos' in > 'posixAccount'? It seems most NSS LDAP clients use attribute 'cn' as > gecos field today." Ah, someone answers my original question! Thanks! :-) > Today the GECOS field is subfielded, holding multiple data items, Frankly I never saw more things like the user's full name put in the GECO= S field or a short description for a demon's system account. My personal us= age of finger is 17+ years ago. > I have never seen an LDAP implementation where GECOS and CN were > synonymous. Hmm, one can only have either LDAP attribute 'cn' or 'gecos' appearing as= passwd's GECOS field. Anyway this is one more reason to question whether posixAccount (or a fut= ure object class serving the same purpose) should have 'cn' (or similar name attribute) as mandatory attribute. In one of my recent setups the NSS LDAP clients can't even read 'cn' or 'gecos'. So "getent passwd" will simply return an empty GECOS field. The system admins are supposed to use LDAP client to find out more about a us= er's account. Yes, it's a paranoid setup. Ciao, Michael. --------------ms050500030301000001050600 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMgTCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGRTCCBS2gAwIBAgIDC01QMA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTQwOTIzMjA0NzU1 WhcNMTUwOTI0MjIwNTE4WjBfMRkwFwYDVQQNExA2TTJZN2k5ekR0ZTZqVXcwMR0wGwYDVQQD DBRtaWNoYWVsQHN0cm9lZGVyLmNvbTEjMCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRl ci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKcgfT19Tn3u/h+Di7CoUk M9TFAdX2rGt8z9ze95K0/JiXQmiuooesP6F8I1n5OjLrk031/287bpaecugMX4UTYORCLrWJ OArmNlOvl0kbVZCSTr3xQ1Y7zuVRYFFhiJQzvALd6TYTSvNH32ojETh0b3DCzX0Xcoom803y 0xPKg/DlWTDirHZJbnhYQEzHugJcEhk88MPyi+V53q8NXB5VJphcVRuTFsolHzsyyKHfgFr5 wzlIAdA1DXWNpImMV6ptCdeN/ScRKe+jRchyRz3DbjTDeNyC7pvlIhAEja+/lNoi/u8qo2TS j5wZz02cLDn/EP84AH0CP+oNxro2F4cJAgMBAAGjggLaMIIC1jAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFOPPUGEQ tk7fMQl+ZlDgj5zo0JciMB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB8GA1Ud EQQYMBaBFG1pY2hhZWxAc3Ryb2VkZXIuY29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEE AYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGlj eS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRo ZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBw b2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBs aWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6Ap oCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEB BIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3Mx L2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMv c3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAB8HJ30IRnmli5Frde4TnF4mgikOiXbYDWYga 5GrFoEUi6aaYOhiv+1WAWh3/d69Ak75p3xPnCmihjjbYeQc3hrVQju6MIpxT8+tBLGa/bwAC yXgWj8idjWdIWMzLxjCPcQb4R2PVmkKTNNE0ZmMFrpSPtRjtRbvWRhxJ0IF7y9z1mLfo6cca RdE5YiKLfAEosMRmrGSfDQKP1NPLmXKWVjPIeS7hpcsM+GJitPOFaLCBibB5ou9b/KphWwdG lby53Oo6vrG9RVy5GZ8xMQ0ztFKVFlXDb7n4j7OfuOo6utQs7UU/sujlw+KWwylIw7Cgmc8t CA1m9c48U7pVoMI5ujGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAwtNUDAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xNDEyMTYyMjExNDBaMCMGCSqGSIb3DQEJBDEWBBSuc+j0dbIH uyncQWfczevitAv7kDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQME AQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIH MA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQIDC01QMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFy eSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMLTVAwDQYJKoZIhvcNAQEBBQAEggEACLiSoydi tP6cPcHprUmk4wCl3MbDyklCdnjuCDbSKs7seo+qrWMqga/lPPcbO9CjditjPN4MX9wPnTg0 4/gUg3gIKRIz6if5n3TycLM9n8Ms55wY6Gs9MAVPlYKqJN/cI7hUT5+WQiLFfnyuj1bwjgg7 goY78jb5La/0EIGzNZaKbBzWlRd8ZjedNi4gtPOgl9d9VdHd3vf/UwzllCeCLDi2DHqcalug GRotKYgkt1mBsjy9awDleBdp9nia6ywjCUIqKyFImdGZjqYaXmmwuKPdd/NvxkFdFIAsVEwy MO9Mujr+fyJlaxnQEVWisKtHzpbck2huUCKrEHc+Othd5AAAAAAAAA== --------------ms050500030301000001050600-- From nobody Wed Dec 17 01:21:45 2014 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64AE11A1B51 for ; Wed, 17 Dec 2014 01:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 lu83HrlD96sq for ; Wed, 17 Dec 2014 01:21:39 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CC761A079A for ; Wed, 17 Dec 2014 01:21:39 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id tr6so14599752ieb.31 for ; Wed, 17 Dec 2014 01:21:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=cVlghpTksbFPgL4Y9/uksosVqX4bgdRmb/RiNYAypLI=; b=DpbZ1C8QumZmaxV388tko5B16E8QrmnLTj22x4fdPXg/A/gcukMdPtR66ksPBxN5sQ ji7zU9bhcLX9wKDHt76hy7o8wV731v7r5Y6SmAevmoUFXtIxwDRy3JtQA2nCivryQ+9Y DHa5HDUBcKQXWQlwBDAxWZSPyS7n5riMJLg9LiMhRphssImu7VPDBj/B6ffpKQLhMCgK KoGbTVUTOY4lkt/lI5NLA/cRFGm5d7SFKoO5+1eE1f3S3AfIeTQY/oS75jC56uavE01r vMGRDrNJs+XZdAOXoCjvGLg/LPJUiHoHPngOUh+PxW23TkG4QtaSJYQso4n8j8iqW7L8 5mWg== X-Gm-Message-State: ALoCoQl4BKutcFrimhtaVVaYFsFPp9YAGHFD0MBT1QiKuawLhMeCtljKuO0dze3Hl+GTPeSuWYMm X-Received: by 10.42.11.15 with SMTP id s15mr29587870ics.18.1418808098957; Wed, 17 Dec 2014 01:21:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.24.162 with HTTP; Wed, 17 Dec 2014 01:21:18 -0800 (PST) In-Reply-To: <5490AE1C.6010004@stroeder.com> References: <548DB67C.5060009@stroeder.com> <5490AE1C.6010004@stroeder.com> From: Jim Willeke Date: Wed, 17 Dec 2014 04:21:18 -0500 Message-ID: To: =?UTF-8?Q?Michael_Str=C3=B6der?= Content-Type: multipart/alternative; boundary=20cf30434866be452d050a6600b9 Archived-At: http://mailarchive.ietf.org/arch/msg/ldapext/dSVvWoLmxmIFpk7I3ttFuQgWcFo Cc: ldapext Subject: Re: [ldapext] why posixAccount MUST contain 'cn'? X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 09:21:41 -0000 --20cf30434866be452d050a6600b9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Usually see only one value in GECOS. Most of the ones we deal with are when we are doing conversions from NIS or NIS+. Sometimes it is used to hold the employeeNumber or something unique and static to the organization. Using multiple values which are derived from other LDAP attributes is more difficult as some mechanism must be used to maintain the "duplicate" GECOS value(s). =E1=90=A7 -- -jim Jim Willeke On Tue, Dec 16, 2014 at 5:11 PM, Michael Str=C3=B6der wrote: > > Charlie, > > Charlie wrote: > > Michael asked, "Also what's the distinction of 'cn' and 'gecos' in > > 'posixAccount'? It seems most NSS LDAP clients use attribute 'cn' as > > gecos field today." > > Ah, someone answers my original question! Thanks! :-) > > > Today the GECOS field is subfielded, holding multiple data items, > > Frankly I never saw more things like the user's full name put in the GECO= S > field or a short description for a demon's system account. My personal > usage > of finger is 17+ years ago. > > > I have never seen an LDAP implementation where GECOS and CN were > > synonymous. > > Hmm, one can only have either LDAP attribute 'cn' or 'gecos' appearing as > passwd's GECOS field. > > Anyway this is one more reason to question whether posixAccount (or a > future > object class serving the same purpose) should have 'cn' (or similar name > attribute) as mandatory attribute. > > In one of my recent setups the NSS LDAP clients can't even read 'cn' or > 'gecos'. So "getent passwd" will simply return an empty GECOS field. The > system admins are supposed to use LDAP client to find out more about a > user's > account. Yes, it's a paranoid setup. > > Ciao, Michael. > > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www.ietf.org/mailman/listinfo/ldapext > > --20cf30434866be452d050a6600b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Usually see only one value in GECOS.
Most of the ones = we deal with are when we are doing conversions from NIS or NIS+.
=
Sometimes it is used to hold the employeeNumber or something uniqu= e and static to the organization.
Using multiple values whi= ch are derived from other LDAP attributes is more difficult as some mechani= sm must be used to maintain the "duplicate" GECOS value(s).
=

=E1=90=A7=

--
-jim<= br>Jim Willeke

On Tue, Dec 16, 2014 at 5:11 PM, Michael Str= =C3=B6der <michael@stroeder.com> wrote:
Charlie,

Charlie wrote:
> Michael asked,=C2=A0 "Also what's the distinction of 'cn&= #39; and 'gecos' in
> 'posixAccount'?=C2=A0 It seems most NSS LDAP clients use attri= bute 'cn' as
> gecos field today."

Ah, someone answers my original question! Thanks! :-)

> Today the GECOS field is subfielded, holding multiple data items,

Frankly I never saw more things like the user's full name put in= the GECOS
field or a short description for a demon's system account. My personal = usage
of finger is 17+ years ago.

> I have never seen an LDAP implementation where GECOS and CN were
> synonymous.

Hmm, one can only have either LDAP attribute 'cn' or 'ge= cos' appearing as
passwd's GECOS field.

Anyway this is one more reason to question whether posixAccount (or a futur= e
object class serving the same purpose) should have 'cn' (or similar= name
attribute) as mandatory attribute.

In one of my recent setups the NSS LDAP clients can't even read 'cn= ' or
'gecos'. So "getent passwd" will simply return an empty G= ECOS field. The
system admins are supposed to use LDAP client to find out more about a user= 's
account. Yes, it's a paranoid setup.

Ciao, Michael.


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext

--20cf30434866be452d050a6600b9-- From nobody Wed Dec 17 16:43:37 2014 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 850701A00B1 for ; Wed, 17 Dec 2014 16:43:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 9QlRrICw_h2A for ; Wed, 17 Dec 2014 16:43:34 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4B721A00A8 for ; Wed, 17 Dec 2014 16:43:34 -0800 (PST) Received: by us.padl.com with ESMTP id sBI0h49R028317; Wed, 17 Dec 2014 19:43:09 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_9A94DC3D-17F5-425A-B24D-9647DA1C1135" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Luke Howard In-Reply-To: Date: Thu, 18 Dec 2014 11:43:03 +1100 Message-Id: <5BC3F036-F46E-4BF2-926A-96C2E98E6064@padl.com> References: <548DB67C.5060009@stroeder.com> <5490AE1C.6010004@stroeder.com> To: Jim Willeke X-Mailer: Apple Mail (2.1990.1) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,HTML_MESSAGE,RDNS_NONE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Archived-At: http://mailarchive.ietf.org/arch/msg/ldapext/YvG3KLr5s5aUhBzffyBe7a7XK8Y Cc: Ldapext , =?utf-8?Q?Michael_Str=C3=B6der?= Subject: Re: [ldapext] why posixAccount MUST contain 'cn'? X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 00:43:36 -0000 --Apple-Mail=_9A94DC3D-17F5-425A-B24D-9647DA1C1135 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 It is a bit tricky to remember why I made =E2=80=9Ccn=E2=80=9D mandatory = but it probably had something to do with (erroneously) conflating = accounts and people. Something that should be addressed in future = specifications (if they ever happen). The only issue might be that some clients reject entries that are = missing =E2=80=9Ccn=E2=80=9D. -- Luke -- www.lukehoward.com soundcloud.com/lukehoward= --Apple-Mail=_9A94DC3D-17F5-425A-B24D-9647DA1C1135 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
It is a bit tricky to remember why I made = =E2=80=9Ccn=E2=80=9D mandatory but it probably had something to do with = (erroneously) conflating accounts and people. Something that should be = addressed in future specifications (if they ever happen).

The only issue might be = that some clients reject entries that are missing =E2=80=9Ccn=E2=80=9D.

-- = Luke

--
www.lukehoward.com
soundcloud.com/lukehoward
= --Apple-Mail=_9A94DC3D-17F5-425A-B24D-9647DA1C1135-- From nobody Thu Dec 18 01:53:25 2014 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34FDD1A87A0 for ; Thu, 18 Dec 2014 01:53:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 5sKTvj19VWGW for ; Thu, 18 Dec 2014 01:53:22 -0800 (PST) Received: from kea.ourshack.com (kea.ourshack.com [IPv6:2001:470:1f15:20::201]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E1341A6F8C for ; Thu, 18 Dec 2014 01:53:22 -0800 (PST) Received: from 4.9.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.e.7.f.0.d.8.0.0.b.8.0.1.0.0.2.ip6.arpa ([2001:8b0:8d0:f7e1::94] helo=slab.skills-1st.co.uk) by kea.ourshack.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Y1Xlm-0004N6-A5; Thu, 18 Dec 2014 09:53:18 +0000 Received: from andrew by slab.skills-1st.co.uk with local (Exim 4.83) (envelope-from ) id 1Y1Xll-0007aI-Og; Thu, 18 Dec 2014 09:53:17 +0000 Date: Thu, 18 Dec 2014 09:53:17 +0000 From: Andrew Findlay To: Luke Howard Message-ID: <20141218095317.GF6326@slab.skills-1st.co.uk> References: <548DB67C.5060009@stroeder.com> <5490AE1C.6010004@stroeder.com> <5BC3F036-F46E-4BF2-926A-96C2E98E6064@padl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5BC3F036-F46E-4BF2-926A-96C2E98E6064@padl.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Andrew Findlay Archived-At: http://mailarchive.ietf.org/arch/msg/ldapext/v5VXHaVqoB9xWZJgbG0pUzsVtW4 Cc: Ldapext , Michael =?iso-8859-1?Q?Str=F6der?= , Jim Willeke Subject: Re: [ldapext] why posixAccount MUST contain 'cn'? X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 09:53:24 -0000 On Thu, Dec 18, 2014 at 11:43:03AM +1100, Luke Howard wrote: > The only issue might be that some clients reject entries that are missing “cn”. That would be an error in itself, as even mandatory attributes can be hidden by access control and the GECOS field is often empty in /etc/passwd entries so it is clearly not essential. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | ----------------------------------------------------------------------- From nobody Thu Dec 18 03:08:26 2014 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF6081A6FE9 for ; Thu, 18 Dec 2014 03:08:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.351 X-Spam-Level: X-Spam-Status: No, score=-1.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] 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 slQBsCWfludF for ; Thu, 18 Dec 2014 03:08:10 -0800 (PST) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::6]) (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 8BF1A1A07BE for ; Thu, 18 Dec 2014 03:08:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418900887; l=6905; s=domk; d=stroeder.com; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From: Date; bh=9A1Vbh+QxBSGiXQ4f0coUr+wpAg=; b=H/NKw/U0CFdZrzMOExttpCCEFyqEiPtZE41r0WzWbxfaUGDuMjgYM3BQC97uUAP2bON bcLJUYnwo4/tcmX05yhwzVM4UKp8mAJiPP1JZV/sq102QTa6AYp04nwjT1sI1J/2/cdOY etUSfLiHXgC+RFIS3Z4rYB1pkXxY1dm4f6E= X-RZG-AUTH: :IWUHfUGtd9+vE/nIU31usF8LLMefsb7+CgbCKRTRv1L3o9ypgEohmQcL6rToJA== X-RZG-CLASS-ID: mo00 Received: from [10.1.1.5] (p4FDB769C.dip0.t-ipconnect.de [79.219.118.156]) by smtp.strato.de (RZmta 36.3 DYNA|AUTH) with ESMTPSA id R00d25qBIB7iLtN (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate); Thu, 18 Dec 2014 12:07:44 +0100 (CET) Message-ID: <5492B57C.1030402@stroeder.com> Date: Thu, 18 Dec 2014 12:07:40 +0100 From: =?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1 MIME-Version: 1.0 To: Andrew Findlay , Luke Howard References: <548DB67C.5060009@stroeder.com> <5490AE1C.6010004@stroeder.com> <5BC3F036-F46E-4BF2-926A-96C2E98E6064@padl.com> <20141218095317.GF6326@slab.skills-1st.co.uk> In-Reply-To: <20141218095317.GF6326@slab.skills-1st.co.uk> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070905010404040805040008" Archived-At: http://mailarchive.ietf.org/arch/msg/ldapext/gJ00W_Fxufl7oUS2HwYtDAL18sM Cc: Ldapext , Jim Willeke Subject: Re: [ldapext] why posixAccount MUST contain 'cn'? X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 11:08:23 -0000 This is a cryptographically signed message in MIME format. --------------ms070905010404040805040008 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Andrew Findlay wrote: > On Thu, Dec 18, 2014 at 11:43:03AM +1100, Luke Howard wrote: >=20 >> The only issue might be that some clients reject entries that are miss= ing =E2=80=9Ccn=E2=80=9D. >=20 > That would be an error in itself, as even mandatory attributes can be > hidden by access control and the GECOS field is often empty in > /etc/passwd entries so it is clearly not essential. Yepp. That's the case with my paranoid setup where person's name must not= be disclosed to the attached systems. AFAICS the modern NSS clients can deal= with that. Ciao, Michael. --------------ms070905010404040805040008 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMgTCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGRTCCBS2gAwIBAgIDC01QMA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTQwOTIzMjA0NzU1 WhcNMTUwOTI0MjIwNTE4WjBfMRkwFwYDVQQNExA2TTJZN2k5ekR0ZTZqVXcwMR0wGwYDVQQD DBRtaWNoYWVsQHN0cm9lZGVyLmNvbTEjMCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRl ci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKcgfT19Tn3u/h+Di7CoUk M9TFAdX2rGt8z9ze95K0/JiXQmiuooesP6F8I1n5OjLrk031/287bpaecugMX4UTYORCLrWJ OArmNlOvl0kbVZCSTr3xQ1Y7zuVRYFFhiJQzvALd6TYTSvNH32ojETh0b3DCzX0Xcoom803y 0xPKg/DlWTDirHZJbnhYQEzHugJcEhk88MPyi+V53q8NXB5VJphcVRuTFsolHzsyyKHfgFr5 wzlIAdA1DXWNpImMV6ptCdeN/ScRKe+jRchyRz3DbjTDeNyC7pvlIhAEja+/lNoi/u8qo2TS j5wZz02cLDn/EP84AH0CP+oNxro2F4cJAgMBAAGjggLaMIIC1jAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFOPPUGEQ tk7fMQl+ZlDgj5zo0JciMB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB8GA1Ud EQQYMBaBFG1pY2hhZWxAc3Ryb2VkZXIuY29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEE AYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGlj eS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRo ZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBw b2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBs aWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6Ap oCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEB BIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3Mx L2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMv c3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAB8HJ30IRnmli5Frde4TnF4mgikOiXbYDWYga 5GrFoEUi6aaYOhiv+1WAWh3/d69Ak75p3xPnCmihjjbYeQc3hrVQju6MIpxT8+tBLGa/bwAC yXgWj8idjWdIWMzLxjCPcQb4R2PVmkKTNNE0ZmMFrpSPtRjtRbvWRhxJ0IF7y9z1mLfo6cca RdE5YiKLfAEosMRmrGSfDQKP1NPLmXKWVjPIeS7hpcsM+GJitPOFaLCBibB5ou9b/KphWwdG lby53Oo6vrG9RVy5GZ8xMQ0ztFKVFlXDb7n4j7OfuOo6utQs7UU/sujlw+KWwylIw7Cgmc8t CA1m9c48U7pVoMI5ujGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAwtNUDAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xNDEyMTgxMTA3NDBaMCMGCSqGSIb3DQEJBDEWBBRkCvVULheP cHkbUFNaRRxVAZFqMzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQME AQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIH MA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQIDC01QMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFy eSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMLTVAwDQYJKoZIhvcNAQEBBQAEggEAjw1FrNRf Bgm0M11mIIsqQ7X4UDn8SchWaowYa2mf3+hC4bLrDaHhPEHz7TFjhsR6KL+QdjrWt5LxY9FI xJvotMeHvLb5qQI3q2jZWcFrF/INMotly3wTlUIk/M27iB4Ja94CBO9w3AOAlkRXL4oQm7YB 1n8xN/F44m4YBeteTdtBZ2+7JpMJzYEllXF2AMqj4Yz/2MiQkwZKkLiKyV8PGyv43J/t3xxl OZrOSlV6fvWgNGuQB86MN12SaTXbnEnTC7ZqxXeWsUtRmr3fLKaXfAF0Xqz0NFgQHbOeYVGp Kep2Hn+O5W7XWdTWkr3dLDGqAaUKJHWpInBI6Z9oY28srQAAAAAAAA== --------------ms070905010404040805040008--