├── .gitignore ├── .travis.yml ├── COPYING.LESSER.txt ├── COPYING.txt ├── LICENSE.txt ├── MANIFEST.in ├── README.rst ├── _changelog.txt ├── _version.json ├── build-dist.cmd ├── deploy-to-pypi.cmd ├── docs ├── manual │ ├── Makefile │ ├── make.bat │ └── source │ │ ├── changelog.rst │ │ ├── conf.py │ │ └── index.rst └── rfc │ ├── iana_ldap_protocol_mechanism │ └── ldap-parameters.txt │ ├── ldap_best_practices │ ├── errata │ │ └── rfc4521-errata.txt │ ├── rfc4520.txt │ └── rfc4521.txt │ ├── ldap_extension_proposed_standard │ ├── errata │ │ ├── rfc3062-errata.txt │ │ ├── rfc4526-errata.txt │ │ └── rfc4532-errata.txt │ ├── rfc2696.txt │ ├── rfc3045.txt │ ├── rfc3062.txt │ ├── rfc3876.txt │ ├── rfc4525.txt │ ├── rfc4526.txt │ ├── rfc4527.txt │ ├── rfc4528.txt │ ├── rfc4529.txt │ └── rfc4532.txt │ ├── ldap_proposed_standard │ ├── errata │ │ ├── rfc2849-errata.txt │ │ ├── rfc4511-errata.txt │ │ ├── rfc4512-errata.txt │ │ ├── rfc4514-errata.txt │ │ ├── rfc4515-errata.txt │ │ ├── rfc4516-errata.txt │ │ ├── rfc4518-errata.txt │ │ └── rfc4519-errata.txt │ ├── rfc2849.txt │ ├── rfc3672.txt │ ├── rfc3673.txt │ ├── rfc4510.txt │ ├── rfc4511.txt │ ├── rfc4512.txt │ ├── rfc4513.txt │ ├── rfc4514.txt │ ├── rfc4515.txt │ ├── rfc4516.txt │ ├── rfc4517.txt │ ├── rfc4518.txt │ ├── rfc4519.txt │ ├── rfc4530.txt │ └── rfc5020.txt │ ├── other │ ├── errata │ │ ├── rfc2119-errata.txt │ │ ├── rfc2849-errata.txt │ │ ├── rfc3454-errata.txt │ │ ├── rfc4122-errata.txt │ │ ├── rfc4234-errata.txt │ │ └── rfc5234-errata.txt │ ├── rfc2119.txt │ ├── rfc2234.txt │ ├── rfc3454.txt │ ├── rfc4122.txt │ ├── rfc4234.txt │ └── rfc5234.txt │ └── sasl_proposed_standard │ ├── errata │ └── rfc4013-errata.txt │ ├── rfc2831.txt │ ├── rfc4013.txt │ ├── rfc4422.txt │ ├── rfc4752.txt │ └── rfc6331.txt ├── prepare-dist.cmd ├── requirements.txt ├── setup.py ├── sldap3 ├── __init__.py ├── backend │ ├── __init__.py │ └── user │ │ ├── __init__.py │ │ └── json.py ├── core │ ├── __init__.py │ ├── dsa.py │ ├── dua.py │ ├── instance.py │ ├── mock_dsa.py │ └── user.py ├── make_daemon.py ├── make_service.py ├── operation │ ├── __init__.py │ ├── bind.py │ ├── extended.py │ └── unbind.py ├── protocol │ ├── __init__.py │ └── rfc4511.py ├── utils │ └── __init__.py └── version.py ├── test ├── __init__.py └── start.py ├── update_source.py └── upload-to-pypi.cmd /.gitignore: -------------------------------------------------------------------------------- 1 | # python .gitignore from GitHub 2 | 3 | # Byte-compiled / optimized / DLL files 4 | __pycache__/ 5 | *.py[cod] 6 | 7 | # C extensions 8 | *.so 9 | 10 | # Distribution / packaging 11 | .Python 12 | env/ 13 | build/ 14 | develop-eggs/ 15 | dist/ 16 | downloads/ 17 | eggs/ 18 | lib/ 19 | lib64/ 20 | parts/ 21 | sdist/ 22 | var/ 23 | *.egg-info/ 24 | .installed.cfg 25 | *.egg 26 | 27 | # PyInstaller 28 | # Usually these files are written by a python script from a template 29 | # before PyInstaller builds the exe, so as to inject date/other infos into it. 30 | *.manifest 31 | *.spec 32 | 33 | # Installer logs 34 | pip-log.txt 35 | pip-delete-this-directory.txt 36 | 37 | # Unit test / coverage reports 38 | htmlcov/ 39 | .tox/ 40 | .coverage 41 | .cache 42 | nosetests.xml 43 | coverage.xml 44 | 45 | # Translations 46 | *.mo 47 | *.pot 48 | 49 | # Django stuff: 50 | *.log 51 | 52 | # Sphinx documentation 53 | docs/_build/ 54 | docs/manual/build/ 55 | 56 | # PyBuilder 57 | target/ 58 | 59 | # PyCharm 60 | .idea/ 61 | 62 | -------------------------------------------------------------------------------- /.travis.yml: -------------------------------------------------------------------------------- 1 | language: python 2 | python: 3 | - "2.6" 4 | - "2.7" 5 | - "3.4" 6 | - "pypy" 7 | - "pypy3" 8 | sudo: false 9 | env: 10 | # travis - strategy - lazy 11 | # - USERDOMAIN=TRAVIS,SYNC,0 12 | install: 13 | - "pip install ." 14 | script: 15 | - nosetests -s test 16 | -------------------------------------------------------------------------------- /COPYING.LESSER.txt: -------------------------------------------------------------------------------- 1 | GNU LESSER GENERAL PUBLIC LICENSE 2 | Version 3, 29 June 2007 3 | 4 | Copyright (C) 2007 Free Software Foundation, Inc. 5 | Everyone is permitted to copy and distribute verbatim copies 6 | of this license document, but changing it is not allowed. 7 | 8 | 9 | This version of the GNU Lesser General Public License incorporates 10 | the terms and conditions of version 3 of the GNU General Public 11 | License, supplemented by the additional permissions listed below. 12 | 13 | 0. Additional Definitions. 14 | 15 | As used herein, "this License" refers to version 3 of the GNU Lesser 16 | General Public License, and the "GNU GPL" refers to version 3 of the GNU 17 | General Public License. 18 | 19 | "The Library" refers to a covered work governed by this License, 20 | other than an Application or a Combined Work as defined below. 21 | 22 | An "Application" is any work that makes use of an interface provided 23 | by the Library, but which is not otherwise based on the Library. 24 | Defining a subclass of a class defined by the Library is deemed a mode 25 | of using an interface provided by the Library. 26 | 27 | A "Combined Work" is a work produced by combining or linking an 28 | Application with the Library. The particular version of the Library 29 | with which the Combined Work was made is also called the "Linked 30 | Version". 31 | 32 | The "Minimal Corresponding Source" for a Combined Work means the 33 | Corresponding Source for the Combined Work, excluding any source code 34 | for portions of the Combined Work that, considered in isolation, are 35 | based on the Application, and not on the Linked Version. 36 | 37 | The "Corresponding Application Code" for a Combined Work means the 38 | object code and/or source code for the Application, including any data 39 | and utility programs needed for reproducing the Combined Work from the 40 | Application, but excluding the System Libraries of the Combined Work. 41 | 42 | 1. Exception to Section 3 of the GNU GPL. 43 | 44 | You may convey a covered work under sections 3 and 4 of this License 45 | without being bound by section 3 of the GNU GPL. 46 | 47 | 2. Conveying Modified Versions. 48 | 49 | If you modify a copy of the Library, and, in your modifications, a 50 | facility refers to a function or data to be supplied by an Application 51 | that uses the facility (other than as an argument passed when the 52 | facility is invoked), then you may convey a copy of the modified 53 | version: 54 | 55 | a) under this License, provided that you make a good faith effort to 56 | ensure that, in the event an Application does not supply the 57 | function or data, the facility still operates, and performs 58 | whatever part of its purpose remains meaningful, or 59 | 60 | b) under the GNU GPL, with none of the additional permissions of 61 | this License applicable to that copy. 62 | 63 | 3. Object Code Incorporating Material from Library Header Files. 64 | 65 | The object code form of an Application may incorporate material from 66 | a header file that is part of the Library. You may convey such object 67 | code under terms of your choice, provided that, if the incorporated 68 | material is not limited to numerical parameters, data structure 69 | layouts and accessors, or small macros, inline functions and templates 70 | (ten or fewer lines in length), you do both of the following: 71 | 72 | a) Give prominent notice with each copy of the object code that the 73 | Library is used in it and that the Library and its use are 74 | covered by this License. 75 | 76 | b) Accompany the object code with a copy of the GNU GPL and this license 77 | document. 78 | 79 | 4. Combined Works. 80 | 81 | You may convey a Combined Work under terms of your choice that, 82 | taken together, effectively do not restrict modification of the 83 | portions of the Library contained in the Combined Work and reverse 84 | engineering for debugging such modifications, if you also do each of 85 | the following: 86 | 87 | a) Give prominent notice with each copy of the Combined Work that 88 | the Library is used in it and that the Library and its use are 89 | covered by this License. 90 | 91 | b) Accompany the Combined Work with a copy of the GNU GPL and this license 92 | document. 93 | 94 | c) For a Combined Work that displays copyright notices during 95 | execution, include the copyright notice for the Library among 96 | these notices, as well as a reference directing the user to the 97 | copies of the GNU GPL and this license document. 98 | 99 | d) Do one of the following: 100 | 101 | 0) Convey the Minimal Corresponding Source under the terms of this 102 | License, and the Corresponding Application Code in a form 103 | suitable for, and under terms that permit, the user to 104 | recombine or relink the Application with a modified version of 105 | the Linked Version to produce a modified Combined Work, in the 106 | manner specified by section 6 of the GNU GPL for conveying 107 | Corresponding Source. 108 | 109 | 1) Use a suitable shared library mechanism for linking with the 110 | Library. A suitable mechanism is one that (a) uses at run time 111 | a copy of the Library already present on the user's computer 112 | system, and (b) will operate properly with a modified version 113 | of the Library that is interface-compatible with the Linked 114 | Version. 115 | 116 | e) Provide Installation Information, but only if you would otherwise 117 | be required to provide such information under section 6 of the 118 | GNU GPL, and only to the extent that such information is 119 | necessary to install and execute a modified version of the 120 | Combined Work produced by recombining or relinking the 121 | Application with a modified version of the Linked Version. (If 122 | you use option 4d0, the Installation Information must accompany 123 | the Minimal Corresponding Source and Corresponding Application 124 | Code. If you use option 4d1, you must provide the Installation 125 | Information in the manner specified by section 6 of the GNU GPL 126 | for conveying Corresponding Source.) 127 | 128 | 5. Combined Libraries. 129 | 130 | You may place library facilities that are a work based on the 131 | Library side by side in a single library together with other library 132 | facilities that are not Applications and are not covered by this 133 | License, and convey such a combined library under terms of your 134 | choice, if you do both of the following: 135 | 136 | a) Accompany the combined library with a copy of the same work based 137 | on the Library, uncombined with any other library facilities, 138 | conveyed under the terms of this License. 139 | 140 | b) Give prominent notice with the combined library that part of it 141 | is a work based on the Library, and explaining where to find the 142 | accompanying uncombined form of the same work. 143 | 144 | 6. Revised Versions of the GNU Lesser General Public License. 145 | 146 | The Free Software Foundation may publish revised and/or new versions 147 | of the GNU Lesser General Public License from time to time. Such new 148 | versions will be similar in spirit to the present version, but may 149 | differ in detail to address new problems or concerns. 150 | 151 | Each version is given a distinguishing version number. If the 152 | Library as you received it specifies that a certain numbered version 153 | of the GNU Lesser General Public License "or any later version" 154 | applies to it, you have the option of following the terms and 155 | conditions either of that published version or of any later version 156 | published by the Free Software Foundation. If the Library as you 157 | received it does not specify a version number of the GNU Lesser 158 | General Public License, you may choose any version of the GNU Lesser 159 | General Public License ever published by the Free Software Foundation. 160 | 161 | If the Library as you received it specifies that a proxy can decide 162 | whether future versions of the GNU Lesser General Public License shall 163 | apply, that proxy's public statement of acceptance of any version is 164 | permanent authorization for you to choose that version for the 165 | Library. -------------------------------------------------------------------------------- /LICENSE.txt: -------------------------------------------------------------------------------- 1 | This program is free software: you can redistribute it and/or modify 2 | it under the terms of the GNU Lesser General Public License as published 3 | by the Free Software Foundation, either version 3 of the License, or 4 | (at your option) any later version. 5 | 6 | This program is distributed in the hope that it will be useful, 7 | but WITHOUT ANY WARRANTY; without even the implied warranty of 8 | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the 9 | GNU Lesser General Public License for more details. 10 | 11 | You should have received a copy of the GNU Lesser General Public License 12 | along with this program in the COPYING and COPYING.LESSER files. 13 | If not, see . -------------------------------------------------------------------------------- /MANIFEST.in: -------------------------------------------------------------------------------- 1 | include COPYING.txt COPYING.LESSER.txt LICENSE.txt README.rst requirements.txt _version.json 2 | -------------------------------------------------------------------------------- /README.rst: -------------------------------------------------------------------------------- 1 | SLDAP3 2 | ====== 3 | 4 | .. image:: https://pypip.in/version/sldap3/badge.svg 5 | :target: https://pypi.python.org/pypi/sldap3/ 6 | :alt: Latest Version 7 | 8 | .. image:: https://travis-ci.org/cannatag/sldap3.svg?branch=master 9 | :target: https://travis-ci.org/cannatag/sldap3 10 | :alt: TRAVIS-CI build status for master branch 11 | 12 | .. image:: https://pypip.in/license/sldap3/badge.svg 13 | :target: https://pypi.python.org/pypi/sldap3/ 14 | :alt: License 15 | 16 | sldap3 is a strictly RFC 4511 conforming LDAP V3 pure Python **server**. It's a sibling of the **ldap3** client LDAP library. 17 | 18 | Home Page 19 | --------- 20 | 21 | Project home page is https://github.com/cannatag/sldap3 22 | 23 | 24 | Documentation 25 | ------------- 26 | 27 | Documentation is available at http://sldap3.readthedocs.org 28 | 29 | 30 | License 31 | ------- 32 | 33 | The sldap3 project is open source software released under the **LGPL v3 license**. 34 | 35 | 36 | PEP8 Compliance 37 | --------------- 38 | 39 | sldap3 is PEP8 compliant, except for line length. 40 | 41 | 42 | Download 43 | -------- 44 | 45 | Package download is available at https://pypi.python.org/pypi/sldap3. 46 | 47 | 48 | Install 49 | ------- 50 | 51 | Install with **pip install sldap3** 52 | 53 | 54 | Git repository 55 | -------------- 56 | 57 | You can download the latest source at https://github.com/cannatag/sldap3 58 | 59 | 60 | Continuous integration 61 | ---------------------- 62 | 63 | Continuous integration for testing is at https://travis-ci.org/cannatag/sldap3 64 | 65 | Support 66 | ------- 67 | 68 | You can submit support tickets on https://github.com/cannatag/sldap3/issues/new 69 | 70 | 71 | Contact me 72 | ---------- 73 | 74 | For information and suggestions you can contact me at cannatag@gmail.com or you can also a support ticket on https://github.com/cannatag/sldap3/issues/new 75 | 76 | Changelog 77 | --------- 78 | 79 | * 0.0.4a0 2015.04.23 80 | - daemonization working properly 81 | - Thread and Process executors available 82 | 83 | * 0.0.3a6 2015.04.21 84 | - Added backward compatability via the trollius package 85 | - Added Linux daemon capability 86 | - Added Windows service capability 87 | 88 | * 0.0.3a0 2015.04.11 89 | - added extended operation structure 90 | - added multiple DSAs definition 91 | 92 | * 0.0.2a 2015.03.13 93 | - Added event loop 94 | - Added bind (always successful) operation 95 | - Added unbind operation 96 | 97 | = 0.0.1a4 2015.02.28 98 | - Fixed missing _version.json in MANIFEST.in 99 | 100 | * 0.0.1a3 2015.02.27 101 | - Fixed auto versioning 102 | - Fixed auto changelog 103 | 104 | * 0.0.1a1 2015.02.21 105 | - Added sphinx structure 106 | 107 | * 0.0.1a0 - 2015.02.20 108 | - Initial project structure 109 | -------------------------------------------------------------------------------- /_changelog.txt: -------------------------------------------------------------------------------- 1 | * 0.0.4a0 2015.04.23 2 | - daemonization working properly 3 | - Thread and Process executors available 4 | 5 | * 0.0.3a6 2015.04.21 6 | - Added backward compatability via the trollius package 7 | - Added Linux daemon capability 8 | - Added Windows service capability 9 | 10 | * 0.0.3a0 2015.04.11 11 | - added extended operation structure 12 | - added multiple DSAs definition 13 | 14 | * 0.0.2a 2015.03.13 15 | - Added event loop 16 | - Added bind (always successful) operation 17 | - Added unbind operation 18 | 19 | = 0.0.1a4 2015.02.28 20 | - Fixed missing _version.json in MANIFEST.in 21 | 22 | * 0.0.1a3 2015.02.27 23 | - Fixed auto versioning 24 | - Fixed auto changelog 25 | 26 | * 0.0.1a1 2015.02.21 27 | - Added sphinx structure 28 | 29 | * 0.0.1a0 - 2015.02.20 30 | - Initial project structure 31 | -------------------------------------------------------------------------------- /_version.json: -------------------------------------------------------------------------------- 1 | { 2 | "package_folder": ".", 3 | "email": "cannatag@gmail.com", 4 | "status": "development - alpha", 5 | "package_name": "sldap3", 6 | "url": "https://github.com/cannatag/sldap3", 7 | "description": "A strictly RFC 4511 conforming LDAP V3 pure Python server. Same codebase for Python 2, Python3, PyPy and PyPy 3", 8 | "author": "Giovanni Cannata", 9 | "version": "0.0.4a0", 10 | "license": "LGPL v3" 11 | } 12 | -------------------------------------------------------------------------------- /build-dist.cmd: -------------------------------------------------------------------------------- 1 | rd dist build sldap3.egg-info /S /Q 2 | py -3 setup.py clean 3 | py -3 setup.py build sdist --format=gztar 4 | py -3 setup.py build bdist_wininst 5 | py -3 setup.py build bdist_wheel --universal 6 | py -2.6 setup.py bdist_egg 7 | py -2.7 setup.py bdist_egg 8 | py -3 setup.py bdist_egg 9 | -------------------------------------------------------------------------------- /deploy-to-pypi.cmd: -------------------------------------------------------------------------------- 1 | call prepare-dist.cmd 2 | call build-dist.cmd 3 | call upload-to-pypi.cmd 4 | -------------------------------------------------------------------------------- /docs/manual/Makefile: -------------------------------------------------------------------------------- 1 | # Makefile for Sphinx documentation 2 | # 3 | 4 | # You can set these variables from the command line. 5 | SPHINXOPTS = 6 | SPHINXBUILD = sphinx-build 7 | PAPER = 8 | BUILDDIR = build 9 | 10 | # User-friendly check for sphinx-build 11 | ifeq ($(shell which $(SPHINXBUILD) >/dev/null 2>&1; echo $$?), 1) 12 | $(error The '$(SPHINXBUILD)' command was not found. Make sure you have Sphinx installed, then set the SPHINXBUILD environment variable to point to the full path of the '$(SPHINXBUILD)' executable. Alternatively you can add the directory with the executable to your PATH. If you don't have Sphinx installed, grab it from http://sphinx-doc.org/) 13 | endif 14 | 15 | # Internal variables. 16 | PAPEROPT_a4 = -D latex_paper_size=a4 17 | PAPEROPT_letter = -D latex_paper_size=letter 18 | ALLSPHINXOPTS = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) source 19 | # the i18n builder cannot share the environment and doctrees with the others 20 | I18NSPHINXOPTS = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) source 21 | 22 | .PHONY: help clean html dirhtml singlehtml pickle json htmlhelp qthelp devhelp epub latex latexpdf text man changes linkcheck doctest coverage gettext 23 | 24 | help: 25 | @echo "Please use \`make ' where is one of" 26 | @echo " html to make standalone HTML files" 27 | @echo " dirhtml to make HTML files named index.html in directories" 28 | @echo " singlehtml to make a single large HTML file" 29 | @echo " pickle to make pickle files" 30 | @echo " json to make JSON files" 31 | @echo " htmlhelp to make HTML files and a HTML help project" 32 | @echo " qthelp to make HTML files and a qthelp project" 33 | @echo " devhelp to make HTML files and a Devhelp project" 34 | @echo " epub to make an epub" 35 | @echo " latex to make LaTeX files, you can set PAPER=a4 or PAPER=letter" 36 | @echo " latexpdf to make LaTeX files and run them through pdflatex" 37 | @echo " latexpdfja to make LaTeX files and run them through platex/dvipdfmx" 38 | @echo " text to make text files" 39 | @echo " man to make manual pages" 40 | @echo " texinfo to make Texinfo files" 41 | @echo " info to make Texinfo files and run them through makeinfo" 42 | @echo " gettext to make PO message catalogs" 43 | @echo " changes to make an overview of all changed/added/deprecated items" 44 | @echo " xml to make Docutils-native XML files" 45 | @echo " pseudoxml to make pseudoxml-XML files for display purposes" 46 | @echo " linkcheck to check all external links for integrity" 47 | @echo " doctest to run all doctests embedded in the documentation (if enabled)" 48 | @echo " coverage to run coverage check of the documentation (if enabled)" 49 | 50 | clean: 51 | rm -rf $(BUILDDIR)/* 52 | 53 | html: 54 | $(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html 55 | @echo 56 | @echo "Build finished. The HTML pages are in $(BUILDDIR)/html." 57 | 58 | dirhtml: 59 | $(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/dirhtml 60 | @echo 61 | @echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml." 62 | 63 | singlehtml: 64 | $(SPHINXBUILD) -b singlehtml $(ALLSPHINXOPTS) $(BUILDDIR)/singlehtml 65 | @echo 66 | @echo "Build finished. The HTML page is in $(BUILDDIR)/singlehtml." 67 | 68 | pickle: 69 | $(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) $(BUILDDIR)/pickle 70 | @echo 71 | @echo "Build finished; now you can process the pickle files." 72 | 73 | json: 74 | $(SPHINXBUILD) -b json $(ALLSPHINXOPTS) $(BUILDDIR)/json 75 | @echo 76 | @echo "Build finished; now you can process the JSON files." 77 | 78 | htmlhelp: 79 | $(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) $(BUILDDIR)/htmlhelp 80 | @echo 81 | @echo "Build finished; now you can run HTML Help Workshop with the" \ 82 | ".hhp project file in $(BUILDDIR)/htmlhelp." 83 | 84 | qthelp: 85 | $(SPHINXBUILD) -b qthelp $(ALLSPHINXOPTS) $(BUILDDIR)/qthelp 86 | @echo 87 | @echo "Build finished; now you can run "qcollectiongenerator" with the" \ 88 | ".qhcp project file in $(BUILDDIR)/qthelp, like this:" 89 | @echo "# qcollectiongenerator $(BUILDDIR)/qthelp/sldap3.qhcp" 90 | @echo "To view the help file:" 91 | @echo "# assistant -collectionFile $(BUILDDIR)/qthelp/sldap3.qhc" 92 | 93 | devhelp: 94 | $(SPHINXBUILD) -b devhelp $(ALLSPHINXOPTS) $(BUILDDIR)/devhelp 95 | @echo 96 | @echo "Build finished." 97 | @echo "To view the help file:" 98 | @echo "# mkdir -p $$HOME/.local/share/devhelp/sldap3" 99 | @echo "# ln -s $(BUILDDIR)/devhelp $$HOME/.local/share/devhelp/sldap3" 100 | @echo "# devhelp" 101 | 102 | epub: 103 | $(SPHINXBUILD) -b epub $(ALLSPHINXOPTS) $(BUILDDIR)/epub 104 | @echo 105 | @echo "Build finished. The epub file is in $(BUILDDIR)/epub." 106 | 107 | latex: 108 | $(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex 109 | @echo 110 | @echo "Build finished; the LaTeX files are in $(BUILDDIR)/latex." 111 | @echo "Run \`make' in that directory to run these through (pdf)latex" \ 112 | "(use \`make latexpdf' here to do that automatically)." 113 | 114 | latexpdf: 115 | $(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex 116 | @echo "Running LaTeX files through pdflatex..." 117 | $(MAKE) -C $(BUILDDIR)/latex all-pdf 118 | @echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex." 119 | 120 | latexpdfja: 121 | $(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex 122 | @echo "Running LaTeX files through platex and dvipdfmx..." 123 | $(MAKE) -C $(BUILDDIR)/latex all-pdf-ja 124 | @echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex." 125 | 126 | text: 127 | $(SPHINXBUILD) -b text $(ALLSPHINXOPTS) $(BUILDDIR)/text 128 | @echo 129 | @echo "Build finished. The text files are in $(BUILDDIR)/text." 130 | 131 | man: 132 | $(SPHINXBUILD) -b man $(ALLSPHINXOPTS) $(BUILDDIR)/man 133 | @echo 134 | @echo "Build finished. The manual pages are in $(BUILDDIR)/man." 135 | 136 | texinfo: 137 | $(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo 138 | @echo 139 | @echo "Build finished. The Texinfo files are in $(BUILDDIR)/texinfo." 140 | @echo "Run \`make' in that directory to run these through makeinfo" \ 141 | "(use \`make info' here to do that automatically)." 142 | 143 | info: 144 | $(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo 145 | @echo "Running Texinfo files through makeinfo..." 146 | make -C $(BUILDDIR)/texinfo info 147 | @echo "makeinfo finished; the Info files are in $(BUILDDIR)/texinfo." 148 | 149 | gettext: 150 | $(SPHINXBUILD) -b gettext $(I18NSPHINXOPTS) $(BUILDDIR)/locale 151 | @echo 152 | @echo "Build finished. The message catalogs are in $(BUILDDIR)/locale." 153 | 154 | changes: 155 | $(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) $(BUILDDIR)/changes 156 | @echo 157 | @echo "The overview file is in $(BUILDDIR)/changes." 158 | 159 | linkcheck: 160 | $(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) $(BUILDDIR)/linkcheck 161 | @echo 162 | @echo "Link check complete; look for any errors in the above output " \ 163 | "or in $(BUILDDIR)/linkcheck/output.txt." 164 | 165 | doctest: 166 | $(SPHINXBUILD) -b doctest $(ALLSPHINXOPTS) $(BUILDDIR)/doctest 167 | @echo "Testing of doctests in the sources finished, look at the " \ 168 | "results in $(BUILDDIR)/doctest/output.txt." 169 | 170 | coverage: 171 | $(SPHINXBUILD) -b coverage $(ALLSPHINXOPTS) $(BUILDDIR)/coverage 172 | @echo "Testing of coverage in the sources finished, look at the " \ 173 | "results in $(BUILDDIR)/coverage/python.txt." 174 | 175 | xml: 176 | $(SPHINXBUILD) -b xml $(ALLSPHINXOPTS) $(BUILDDIR)/xml 177 | @echo 178 | @echo "Build finished. The XML files are in $(BUILDDIR)/xml." 179 | 180 | pseudoxml: 181 | $(SPHINXBUILD) -b pseudoxml $(ALLSPHINXOPTS) $(BUILDDIR)/pseudoxml 182 | @echo 183 | @echo "Build finished. The pseudo-XML files are in $(BUILDDIR)/pseudoxml." 184 | -------------------------------------------------------------------------------- /docs/manual/make.bat: -------------------------------------------------------------------------------- 1 | @ECHO OFF 2 | 3 | REM Command file for Sphinx documentation 4 | 5 | if "%SPHINXBUILD%" == "" ( 6 | set SPHINXBUILD=sphinx-build 7 | ) 8 | set BUILDDIR=build 9 | set ALLSPHINXOPTS=-d %BUILDDIR%/doctrees %SPHINXOPTS% source 10 | set I18NSPHINXOPTS=%SPHINXOPTS% source 11 | if NOT "%PAPER%" == "" ( 12 | set ALLSPHINXOPTS=-D latex_paper_size=%PAPER% %ALLSPHINXOPTS% 13 | set I18NSPHINXOPTS=-D latex_paper_size=%PAPER% %I18NSPHINXOPTS% 14 | ) 15 | 16 | if "%1" == "" goto help 17 | 18 | if "%1" == "help" ( 19 | :help 20 | echo.Please use `make ^` where ^ is one of 21 | echo. html to make standalone HTML files 22 | echo. dirhtml to make HTML files named index.html in directories 23 | echo. singlehtml to make a single large HTML file 24 | echo. pickle to make pickle files 25 | echo. json to make JSON files 26 | echo. htmlhelp to make HTML files and a HTML help project 27 | echo. qthelp to make HTML files and a qthelp project 28 | echo. devhelp to make HTML files and a Devhelp project 29 | echo. epub to make an epub 30 | echo. latex to make LaTeX files, you can set PAPER=a4 or PAPER=letter 31 | echo. text to make text files 32 | echo. man to make manual pages 33 | echo. texinfo to make Texinfo files 34 | echo. gettext to make PO message catalogs 35 | echo. changes to make an overview over all changed/added/deprecated items 36 | echo. xml to make Docutils-native XML files 37 | echo. pseudoxml to make pseudoxml-XML files for display purposes 38 | echo. linkcheck to check all external links for integrity 39 | echo. doctest to run all doctests embedded in the documentation if enabled 40 | echo. coverage to run coverage check of the documentation if enabled 41 | goto end 42 | ) 43 | 44 | if "%1" == "clean" ( 45 | for /d %%i in (%BUILDDIR%\*) do rmdir /q /s %%i 46 | del /q /s %BUILDDIR%\* 47 | goto end 48 | ) 49 | 50 | 51 | REM Check if sphinx-build is available and fallback to Python version if any 52 | %SPHINXBUILD% 2> nul 53 | if errorlevel 9009 goto sphinx_python 54 | goto sphinx_ok 55 | 56 | :sphinx_python 57 | 58 | set SPHINXBUILD=python -m sphinx.__init__ 59 | %SPHINXBUILD% 2> nul 60 | if errorlevel 9009 ( 61 | echo. 62 | echo.The 'sphinx-build' command was not found. Make sure you have Sphinx 63 | echo.installed, then set the SPHINXBUILD environment variable to point 64 | echo.to the full path of the 'sphinx-build' executable. Alternatively you 65 | echo.may add the Sphinx directory to PATH. 66 | echo. 67 | echo.If you don't have Sphinx installed, grab it from 68 | echo.http://sphinx-doc.org/ 69 | exit /b 1 70 | ) 71 | 72 | :sphinx_ok 73 | 74 | 75 | if "%1" == "html" ( 76 | %SPHINXBUILD% -b html %ALLSPHINXOPTS% %BUILDDIR%/html 77 | if errorlevel 1 exit /b 1 78 | echo. 79 | echo.Build finished. The HTML pages are in %BUILDDIR%/html. 80 | goto end 81 | ) 82 | 83 | if "%1" == "dirhtml" ( 84 | %SPHINXBUILD% -b dirhtml %ALLSPHINXOPTS% %BUILDDIR%/dirhtml 85 | if errorlevel 1 exit /b 1 86 | echo. 87 | echo.Build finished. The HTML pages are in %BUILDDIR%/dirhtml. 88 | goto end 89 | ) 90 | 91 | if "%1" == "singlehtml" ( 92 | %SPHINXBUILD% -b singlehtml %ALLSPHINXOPTS% %BUILDDIR%/singlehtml 93 | if errorlevel 1 exit /b 1 94 | echo. 95 | echo.Build finished. The HTML pages are in %BUILDDIR%/singlehtml. 96 | goto end 97 | ) 98 | 99 | if "%1" == "pickle" ( 100 | %SPHINXBUILD% -b pickle %ALLSPHINXOPTS% %BUILDDIR%/pickle 101 | if errorlevel 1 exit /b 1 102 | echo. 103 | echo.Build finished; now you can process the pickle files. 104 | goto end 105 | ) 106 | 107 | if "%1" == "json" ( 108 | %SPHINXBUILD% -b json %ALLSPHINXOPTS% %BUILDDIR%/json 109 | if errorlevel 1 exit /b 1 110 | echo. 111 | echo.Build finished; now you can process the JSON files. 112 | goto end 113 | ) 114 | 115 | if "%1" == "htmlhelp" ( 116 | %SPHINXBUILD% -b htmlhelp %ALLSPHINXOPTS% %BUILDDIR%/htmlhelp 117 | if errorlevel 1 exit /b 1 118 | echo. 119 | echo.Build finished; now you can run HTML Help Workshop with the ^ 120 | .hhp project file in %BUILDDIR%/htmlhelp. 121 | goto end 122 | ) 123 | 124 | if "%1" == "qthelp" ( 125 | %SPHINXBUILD% -b qthelp %ALLSPHINXOPTS% %BUILDDIR%/qthelp 126 | if errorlevel 1 exit /b 1 127 | echo. 128 | echo.Build finished; now you can run "qcollectiongenerator" with the ^ 129 | .qhcp project file in %BUILDDIR%/qthelp, like this: 130 | echo.^> qcollectiongenerator %BUILDDIR%\qthelp\sldap3.qhcp 131 | echo.To view the help file: 132 | echo.^> assistant -collectionFile %BUILDDIR%\qthelp\sldap3.ghc 133 | goto end 134 | ) 135 | 136 | if "%1" == "devhelp" ( 137 | %SPHINXBUILD% -b devhelp %ALLSPHINXOPTS% %BUILDDIR%/devhelp 138 | if errorlevel 1 exit /b 1 139 | echo. 140 | echo.Build finished. 141 | goto end 142 | ) 143 | 144 | if "%1" == "epub" ( 145 | %SPHINXBUILD% -b epub %ALLSPHINXOPTS% %BUILDDIR%/epub 146 | if errorlevel 1 exit /b 1 147 | echo. 148 | echo.Build finished. The epub file is in %BUILDDIR%/epub. 149 | goto end 150 | ) 151 | 152 | if "%1" == "latex" ( 153 | %SPHINXBUILD% -b latex %ALLSPHINXOPTS% %BUILDDIR%/latex 154 | if errorlevel 1 exit /b 1 155 | echo. 156 | echo.Build finished; the LaTeX files are in %BUILDDIR%/latex. 157 | goto end 158 | ) 159 | 160 | if "%1" == "latexpdf" ( 161 | %SPHINXBUILD% -b latex %ALLSPHINXOPTS% %BUILDDIR%/latex 162 | cd %BUILDDIR%/latex 163 | make all-pdf 164 | cd %~dp0 165 | echo. 166 | echo.Build finished; the PDF files are in %BUILDDIR%/latex. 167 | goto end 168 | ) 169 | 170 | if "%1" == "latexpdfja" ( 171 | %SPHINXBUILD% -b latex %ALLSPHINXOPTS% %BUILDDIR%/latex 172 | cd %BUILDDIR%/latex 173 | make all-pdf-ja 174 | cd %~dp0 175 | echo. 176 | echo.Build finished; the PDF files are in %BUILDDIR%/latex. 177 | goto end 178 | ) 179 | 180 | if "%1" == "text" ( 181 | %SPHINXBUILD% -b text %ALLSPHINXOPTS% %BUILDDIR%/text 182 | if errorlevel 1 exit /b 1 183 | echo. 184 | echo.Build finished. The text files are in %BUILDDIR%/text. 185 | goto end 186 | ) 187 | 188 | if "%1" == "man" ( 189 | %SPHINXBUILD% -b man %ALLSPHINXOPTS% %BUILDDIR%/man 190 | if errorlevel 1 exit /b 1 191 | echo. 192 | echo.Build finished. The manual pages are in %BUILDDIR%/man. 193 | goto end 194 | ) 195 | 196 | if "%1" == "texinfo" ( 197 | %SPHINXBUILD% -b texinfo %ALLSPHINXOPTS% %BUILDDIR%/texinfo 198 | if errorlevel 1 exit /b 1 199 | echo. 200 | echo.Build finished. The Texinfo files are in %BUILDDIR%/texinfo. 201 | goto end 202 | ) 203 | 204 | if "%1" == "gettext" ( 205 | %SPHINXBUILD% -b gettext %I18NSPHINXOPTS% %BUILDDIR%/locale 206 | if errorlevel 1 exit /b 1 207 | echo. 208 | echo.Build finished. The message catalogs are in %BUILDDIR%/locale. 209 | goto end 210 | ) 211 | 212 | if "%1" == "changes" ( 213 | %SPHINXBUILD% -b changes %ALLSPHINXOPTS% %BUILDDIR%/changes 214 | if errorlevel 1 exit /b 1 215 | echo. 216 | echo.The overview file is in %BUILDDIR%/changes. 217 | goto end 218 | ) 219 | 220 | if "%1" == "linkcheck" ( 221 | %SPHINXBUILD% -b linkcheck %ALLSPHINXOPTS% %BUILDDIR%/linkcheck 222 | if errorlevel 1 exit /b 1 223 | echo. 224 | echo.Link check complete; look for any errors in the above output ^ 225 | or in %BUILDDIR%/linkcheck/output.txt. 226 | goto end 227 | ) 228 | 229 | if "%1" == "doctest" ( 230 | %SPHINXBUILD% -b doctest %ALLSPHINXOPTS% %BUILDDIR%/doctest 231 | if errorlevel 1 exit /b 1 232 | echo. 233 | echo.Testing of doctests in the sources finished, look at the ^ 234 | results in %BUILDDIR%/doctest/output.txt. 235 | goto end 236 | ) 237 | 238 | if "%1" == "coverage" ( 239 | %SPHINXBUILD% -b coverage %ALLSPHINXOPTS% %BUILDDIR%/coverage 240 | if errorlevel 1 exit /b 1 241 | echo. 242 | echo.Testing of coverage in the sources finished, look at the ^ 243 | results in %BUILDDIR%/coverage/python.txt. 244 | goto end 245 | ) 246 | 247 | if "%1" == "xml" ( 248 | %SPHINXBUILD% -b xml %ALLSPHINXOPTS% %BUILDDIR%/xml 249 | if errorlevel 1 exit /b 1 250 | echo. 251 | echo.Build finished. The XML files are in %BUILDDIR%/xml. 252 | goto end 253 | ) 254 | 255 | if "%1" == "pseudoxml" ( 256 | %SPHINXBUILD% -b pseudoxml %ALLSPHINXOPTS% %BUILDDIR%/pseudoxml 257 | if errorlevel 1 exit /b 1 258 | echo. 259 | echo.Build finished. The pseudo-XML files are in %BUILDDIR%/pseudoxml. 260 | goto end 261 | ) 262 | 263 | :end 264 | -------------------------------------------------------------------------------- /docs/manual/source/changelog.rst: -------------------------------------------------------------------------------- 1 | CHANGELOG 2 | ========= 3 | .. include:: ../../../_changelog.txt 4 | -------------------------------------------------------------------------------- /docs/manual/source/index.rst: -------------------------------------------------------------------------------- 1 | .. sldap3 documentation master file, created by 2 | sphinx-quickstart on Fri Feb 20 21:34:00 2015. 3 | You can adapt this file completely to your liking, but it should at least 4 | contain the root `toctree` directive. 5 | 6 | Welcome to sldap3's documentation! 7 | ================================== 8 | 9 | 10 | ldap3 is a pure Python LDAP 3 **server** library strictly conforming to RFC4511 released under the LGPL v3 open source license. 11 | RFC4511 is the current LDAP specification (June 2006) from IETF and obsoletes the previous LDAP RFCs 2251, 2830, 3771 (December 1997) 12 | 13 | sldap3 can be used on Python 3 and Python 2 (starting from python 2.6). It works on PyPy and PyPy3. 14 | 15 | Contents: 16 | 17 | .. toctree:: 18 | :maxdepth: 2 19 | 20 | changelog 21 | 22 | Indices and tables 23 | ================== 24 | 25 | * :ref:`genindex` 26 | * :ref:`modindex` 27 | * :ref:`search` 28 | 29 | -------------------------------------------------------------------------------- /docs/rfc/ldap_best_practices/errata/rfc4521-errata.txt: -------------------------------------------------------------------------------- 1 | Errata ID: 69 2 | 3 | Status: Held for Document Update 4 | Type: Editorial 5 | 6 | Reported By: Alfred Hoenes 7 | Date Reported: 2006-06-22 8 | Held for Document Update by: Peter Saint-Andre 9 | 10 | 11 | (1) Section 2.5 (page 5) -- Ref. tags 12 | 13 | The text, 14 | vvvvvvvv 15 | Numerous elements of LDAP are described using ASN.1 [X.680] and are 16 | | encoded using a particular subset [Protocol, Section 5.2] of the 17 | Basic Encoding Rules (BER) [X.690]. To allow reuse of 18 | parsers/generators used in implementing the LDAP "core" technical 19 | specification [RFC4510], it is RECOMMENDED that extension elements 20 | (e.g., extension specific contents of controlValue, requestValue, 21 | responseValue fields) described by ASN.1 and encoded using BER be 22 | | subjected to the restrictions of [Protocol, Section 5.2]. 23 | ^^^^^^^^ 24 | should say: 25 | 26 | Numerous elements of LDAP are described using ASN.1 [X.680] and are 27 | | encoded using a particular subset [RFC4511, Section 5.1] of the 28 | Basic Encoding Rules (BER) [X.690]. To allow reuse of 29 | parsers/generators used in implementing the LDAP "core" technical 30 | specification [RFC4510], it is RECOMMENDED that extension elements 31 | (e.g., extension specific contents of controlValue, requestValue, 32 | responseValue fields) described by ASN.1 and encoded using BER be 33 | | subjected to the restrictions of [RFC4511, Section 5.1]. 34 | 35 | [ Note: the tags *and* the section numbers need correction! ] 36 | 37 | 38 | (2) Section 3.1 (page 6), 3rd and 4th paragraph -- Ref. tags 39 | 40 | The text: 41 | 42 | An existing operation MAY be extended to return IntermediateResponse 43 | | messages [Protocol, Section 4.13]. 44 | ^^^^^^^^ vvvvvvvv 45 | Specifications of controls SHALL NOT attach additional semantics to 46 | | the criticality of controls beyond those defined in [Protocol, 47 | Section 4.1.11]. A specification MAY mandate the criticality take on 48 | a particular value (e.g., TRUE or FALSE), where appropriate. 49 | 50 | should say: 51 | 52 | An existing operation MAY be extended to return IntermediateResponse 53 | | messages [RFC4511, Section 4.13]. 54 | 55 | Specifications of controls SHALL NOT attach additional semantics to 56 | | the criticality of controls beyond those defined in [RFC4511, Section 57 | 4.1.11]. A specification MAY mandate the criticality take on a 58 | particular value (e.g., TRUE or FALSE), where appropriate. 59 | 60 | 61 | (3) Section 3.1.2 (page 7), 3rd paragraph -- typo 62 | 63 | The text: 64 | 65 | It is RECOMMENDED that designers consider alternative mechanisms for 66 | providing the function. For example, an extended operation issued 67 | subsequent to the Start TLS operation (hence, protected by the 68 | security layers negotiated by the Start TLS operation) might be used 69 | | to provided the desired function. 70 | ^ 71 | should say: 72 | 73 | It is RECOMMENDED that designers consider alternative mechanisms for 74 | providing the function. For example, an extended operation issued 75 | subsequent to the Start TLS operation (hence, protected by the 76 | security layers negotiated by the Start TLS operation) might be used 77 | | to provide the desired function. 78 | 79 | 80 | (4) Section 3.1.4 (page 8), 2nd bullet -- typo 81 | 82 | The text: 83 | vvvv 84 | | - consistency: The resulting DIT state must be conform to schema 85 | and other constraints. 86 | 87 | should say: 88 | 89 | | - consistency: The resulting DIT state must conform to schema and 90 | other constraints. 91 | 92 | 93 | (5) Section 3.2 (page 8) -- Ref. tag 94 | 95 | The text: 96 | vvvvvvvv 97 | | Extended Operations [Protocol, Section 4.12] are the RECOMMENDED 98 | mechanism for defining new operations. [...] 99 | 100 | should say: 101 | 102 | | Extended Operations [RFC4511, Section 4.12] are the RECOMMENDED 103 | mechanism for defining new operations. [...] 104 | 105 | 106 | (6) Section 3.4 (page 9), 1st paragraph -- Ref. tag 107 | 108 | The text: 109 | vvvvvvvv 110 | | Unsolicited notifications [Protocol, Section 4.4] offer a capability 111 | for the server to notify the client of events not associated with the 112 | operation currently being processed. 113 | 114 | should say: 115 | 116 | | Unsolicited notifications [RFC4511, Section 4.4] offer a capability 117 | for the server to notify the client of events not associated with the 118 | operation currently being processed. 119 | 120 | 121 | (7) Section 4 (page 9) -- Ref. tags 122 | 123 | The text: 124 | vvvvvvvv 125 | | LDAP allows limited extension [Protocol, Section 4] of the LDAP ASN.1 126 | | definition [Protocol, Appendix B] to be made. 127 | ^^^^^^^^ 128 | should say: 129 | 130 | | LDAP allows limited extension [RFC4511, Section 4] of the LDAP ASN.1 131 | | definition [RFC4511, Appendix B] to be made. 132 | 133 | 134 | (8) Section 5 (page 10), 1st paragraph -- Ref. tag 135 | 136 | The text: 137 | 138 | Extensions defining LDAP schema elements SHALL provide schema 139 | | definitions conforming with syntaxes defined in [Models, Section 140 | 4.1]. [...] 141 | ^^^^^^ 142 | should say: 143 | 144 | Extensions defining LDAP schema elements SHALL provide schema 145 | | definitions conforming with syntaxes defined in [RFC4512, Section 146 | 4.1]. [...] 147 | 148 | 149 | (9) Section 9.1 (page 13) -- duplicate entry 150 | 151 | The entry at the bottom of page 13, 152 | 153 | [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol 154 | (LDAP): Directory Information Models", RFC 4512, June 155 | 2006. 156 | 157 | should be deleted. 158 | This entry is a duplicate, and it recurs on page 14, at the proper 159 | place according to the collation order (by ascending RFC#). 160 | Notes: 161 | 162 | Most important issue: 163 | Apparently, the update of the Reference tags within the text has 164 | been performed incompletely after the assignment of RFC numbers 165 | to those many LDAP I-Ds, leaving 'unsatisfied' tags in the text 166 | (not listed in the References Sections), wherever these tags give 167 | detailed citations, specifying a section or an Appendix there. 168 | 169 | The errata detail items below are listed in textual order. 170 | I use change bars and tag lines to emphasize the corrections 171 | proposed and/or the issues in the original text. 172 | Changed text is re-adjusted to conform to RFC formatting rules. 173 | 174 | from pending 175 | 176 | -------------------------------------------------------------------------------- /docs/rfc/ldap_extension_proposed_standard/errata/rfc3062-errata.txt: -------------------------------------------------------------------------------- 1 | Errata ID: 340 2 | 3 | Status: Verified 4 | Type: Technical 5 | 6 | Reported By: Kurt Zeilenga 7 | Date Reported: 2001-03-07 8 | Section 1 says: 9 | 10 | Traditionally, LDAP users where identified by the Distinguished Name 11 | [RFC2253] of a directory entry and this entry contained a userPassword 12 | [RFC2256] attribute containing one or more passwords. 13 | It should say: 14 | 15 | Traditionally, LDAP users were identified by the Distinguished 16 | Name [RFC2253] of a directory entry and this entry contained a 17 | userPassword [RFC2256] attribute containing one or more passwords. 18 | -------------------------------------------------------------------------------- /docs/rfc/ldap_extension_proposed_standard/errata/rfc4526-errata.txt: -------------------------------------------------------------------------------- 1 | Errata ID: 67 2 | 3 | Status: Rejected 4 | Type: Editorial 5 | 6 | Reported By: Alfred Hoenes 7 | Date Reported: 2006-07-06 8 | Rejected by: Peter Saint-Andre 9 | Date Rejected: 2010-09-15 10 | 11 | Section 4 says: 12 | 13 | Subject: Request for LDAP Protocol Mechanism Registration Object 14 | Identifier: 1.3.6.1.4.1.4203.1.5.3 Description: True/False filters 15 | Person & email address to contact for further information: 16 | Kurt Zeilenga Usage: Feature Specification: 17 | RFC 4526 Author/Change Controller: IESG Comments: none 18 | 19 | It should say: 20 | 21 | Subject: Request for LDAP Protocol Mechanism Registration 22 | Object Identifier: 1.3.6.1.4.1.4203.1.5.3 23 | Description: True/False filters 24 | Person & email address to contact for further information: 25 | Kurt Zeilenga 26 | Usage: Feature 27 | Specification: RFC 4526 28 | Author/Change Controller: IESG 29 | Comments: none 30 | 31 | 32 | Notes: 33 | 34 | 35 | --VERIFIER NOTES-- 36 | Although the RFC text has unfortunate line breaks, the registration with the IANA is accurate at http://www.iana.org/assignments/ldap-parameters 37 | -------------------------------------------------------------------------------- /docs/rfc/ldap_extension_proposed_standard/errata/rfc4532-errata.txt: -------------------------------------------------------------------------------- 1 | Errata ID: 65 2 | 3 | Status: Verified 4 | Type: Editorial 5 | 6 | Reported By: Alfred Hoenes 7 | Date Reported: 2006-07-06 8 | Verifier Name: Alexey Melnikov 9 | Date Verified: 2010-09-02 10 | Section 3 says: 11 | 12 | Servers indicate their support for this extended operation by 13 | providing a whoamiOID object identifier as a value of the 14 | 'supportedExtension' attribute type in their root DSE. The server 15 | SHOULD advertise this extension only when the client is willing and 16 | ^^^^^^^^^^ 17 | able to perform this operation. 18 | It should say: 19 | 20 | Servers indicate their support for this extended operation by 21 | providing a whoamiOID object identifier as a value of the 22 | 'supportedExtension' attribute type in their root DSE. The server 23 | SHOULD advertise this extension only when it is willing 24 | ^^ 25 | and able to perform this operation. 26 | 27 | Notes: 28 | 29 | As far as I can see, the last sentence there is misleading and 30 | does not match the operational scenario; and hence, it should be 31 | clarified. According to the recommendations given, the client 32 | will not try the operation if the OID is not offered by the server, 33 | and hence the server cannot know whether the client is willing 34 | to send the whoami Request; and in this case, the *server* will 35 | perform the operation, i.e., send the whoami Response. -------------------------------------------------------------------------------- /docs/rfc/ldap_extension_proposed_standard/rfc3045.txt: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | Network Working Group M. Meredith 8 | Request for Comments: 3045 Novell Inc. 9 | Category: Informational January 2001 10 | 11 | 12 | Storing Vendor Information in the LDAP root DSE 13 | 14 | Status of this Memo 15 | 16 | This memo provides information for the Internet community. It does 17 | not specify an Internet standard of any kind. Distribution of this 18 | memo is unlimited. 19 | 20 | Copyright Notice 21 | 22 | Copyright (C) The Internet Society (2001). All Rights Reserved. 23 | 24 | Abstract 25 | 26 | This document specifies two Lightweight Directory Access Protocol 27 | (LDAP) attributes, vendorName and vendorVersion that MAY be included 28 | in the root DSA-specific Entry (DSE) to advertise vendor-specific 29 | information. These two attributes supplement the attributes defined 30 | in section 3.4 of RFC 2251. 31 | 32 | The information held in these attributes MAY be used for display and 33 | informational purposes and MUST NOT be used for feature advertisement 34 | or discovery. 35 | 36 | Conventions used in this document 37 | 38 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 39 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 40 | document are to be interpreted as described in [RFC2219] 41 | 42 | 1. Overview 43 | 44 | LDAP clients discover server-specific data--such as available 45 | controls, extensions, etc.--by reading the root DSE. See section 3.4 46 | of [RFC2251] for details. 47 | 48 | For display, information, and limited function discovery, it is 49 | desirable to be able to query an LDAP server to determine the vendor 50 | name of that server and also to see what version of that vendor's 51 | code is currently installed. 52 | 53 | 54 | 55 | 56 | 57 | 58 | Meredith Informational [Page 1] 59 | 60 | RFC 3045 LDAP Root DSE to Display Vendor Information January 2001 61 | 62 | 63 | 1.1 Function discovery 64 | 65 | There are many ways in which a particular version of a vendor's LDAP 66 | server implementation may be functionally incomplete, or may contain 67 | software anomalies. It is impossible to identify every known 68 | shortcoming of an LDAP server with the given set of server data 69 | advertisement attributes. Furthermore, often times, the anomalies of 70 | an implementation are not found until after the implementation has 71 | been distributed, deployed, and is in use. 72 | 73 | The attributes defined in this document MAY be used by client 74 | implementations in order to identify a particular server 75 | implementation so that it can 'work around' such anomalies. 76 | 77 | The attributes defined in this document MUST NOT be used to gather 78 | information related to supported features of an LDAP implementation. 79 | All LDAP features, mechanisms, and capabilities--if advertised--MUST 80 | be advertised through other mechanisms, preferably advertisement 81 | mechanisms defined in concert with said features, mechanisms, and 82 | capabilities. 83 | 84 | 2. Attribute Types 85 | 86 | These attributes are an addition to the Server-specific Data 87 | Requirements defined in section 3.4 of [RFC2251]. The associated 88 | syntaxes are defined in section 4 of [RFC2252]. 89 | 90 | Servers MAY restrict access to vendorName or vendorVersion and 91 | clients MUST NOT expect these attributes to be available. 92 | 93 | 2.1 vendorName 94 | 95 | This attribute contains a single string, which represents the name of 96 | the LDAP server implementer. 97 | 98 | All LDAP server implementations SHOULD maintain a vendorName, which 99 | is generally the name of the company that wrote the LDAP Server code 100 | like "Novell, Inc." 101 | 102 | ( 1.3.6.1.1.4 NAME 'vendorName' EQUALITY 103 | 1.3.6.1.4.1.1466.109.114.1 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 104 | SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation ) 105 | 106 | 2.2 vendorVersion 107 | 108 | This attribute contains a string which represents the version of the 109 | LDAP server implementation. 110 | 111 | 112 | 113 | 114 | Meredith Informational [Page 2] 115 | 116 | RFC 3045 LDAP Root DSE to Display Vendor Information January 2001 117 | 118 | 119 | All LDAP server implementations SHOULD maintain a vendorVersion. 120 | Note that this value is typically a release value--comprised of a 121 | string and/or a string of numbers--used by the developer of the LDAP 122 | server product (as opposed to the supportedLDAPVersion, which 123 | specifies the version of the LDAP protocol supported by this server). 124 | This is single-valued so that it will only have one version value. 125 | This string MUST be unique between two versions, but there are no 126 | other syntactic restrictions on the value or the way it is formatted. 127 | 128 | ( 1.3.6.1.1.5 NAME 'vendorVersion' EQUALITY 129 | 1.3.6.1.4.1.1466.109.114.1 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 130 | SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation ) 131 | 132 | The intent behind the equality match on vendorVersion is to not allow 133 | a less than or greater than type of query. Say release "LDAPv3 8.0" 134 | has a problem that is fixed in the next release "LDAPv3 8.5", but in 135 | the mean time there is also an update release say version "LDAPv3 136 | 8.01" that fixes the problem. This will hopefully stop the client 137 | from saying it will not work with a version less than "LDAPv3 8.5" 138 | when it would also work with "LDAPv3 8.01". With the equality match 139 | the client would have to exactly match what it is looking for. 140 | 141 | 3. Notes to Server Implementers 142 | 143 | Server implementers may consider tying the vendorVersion attribute 144 | value to the build mechanism so that it is automatically updated when 145 | the version value changes. 146 | 147 | 4. Notes to Client Developers 148 | 149 | As mentioned in section 2.1, the use of vendorName and vendorVersion 150 | MUST NOT be used to discover features. 151 | 152 | It should be noted that an anomalies often on affect subset of 153 | implementations reporting the same version information. Most 154 | implementations support multiple platforms, have numerous 155 | configuration options, and often support plug-ins. 156 | 157 | Client implementations SHOULD be written in such a way as to accept 158 | any value in the vendorName and vendorVersion attributes. If a 159 | client implementation does not recognize the specific vendorName or 160 | vendorVersion as one it recognizes, then for the purposes of 'working 161 | around' anomalies, the client MUST assume that the server is complete 162 | and correct. The client MUST work with implementations that do not 163 | publish these attributes. 164 | 165 | 166 | 167 | 168 | 169 | 170 | Meredith Informational [Page 3] 171 | 172 | RFC 3045 LDAP Root DSE to Display Vendor Information January 2001 173 | 174 | 175 | 5. Security Considerations 176 | 177 | The vendorName and vendorVersion attributes are provided only as 178 | display or informational mechanisms, or as anomaly identifying 179 | mechanisms. Client and application implementers must consider that 180 | the existence of a given value in the vendorName or vendorVersion 181 | attribute is no guarantee that the server was actually built by the 182 | asserted vendor or that its version is the asserted version and 183 | should act accordingly. 184 | 185 | Server implementers should be aware that this information could be 186 | used to exploit a security hole a server provides either by feature 187 | or flaw. 188 | 189 | 6. IANA Considerations 190 | 191 | This document seeks to create two attributes, vendorName and 192 | vendorVersion, which the IANA will primarily be responsible. This is 193 | a one time effort; there is no need for any recurring assignment 194 | after this stage. 195 | 196 | 7. References 197 | 198 | [RFC2219] Bradner, S., "Key words for use in RFCs to Indicate 199 | Requirement Levels", BCP 14, RFC 2119, March 1997. 200 | 201 | [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 202 | 3", BCP 9, RFC 2026, October 1996. 203 | 204 | [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory 205 | Access Protocol (v3)", RFC 2251, December 1997. 206 | 207 | [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, 208 | "Lightweight Directory Access Protocol (v3): Attribute 209 | Syntax Definitions", RFC 2252, December 1997. 210 | 211 | 8. Acknowledgments 212 | 213 | The author would like to thank the generous input and review by 214 | individuals at Novell including but not limited to Jim Sermersheim, 215 | Mark Hinckley, Renea Campbell, and Roger Harrison. Also IETF 216 | contributors Kurt Zeilenga, Mark Smith, Mark Wahl, Peter Strong, 217 | Thomas Salter, Gordon Good, Paul Leach, Helmut Volpers. 218 | 219 | 220 | 221 | 222 | 223 | 224 | 225 | 226 | Meredith Informational [Page 4] 227 | 228 | RFC 3045 LDAP Root DSE to Display Vendor Information January 2001 229 | 230 | 231 | 9. Author's Address 232 | 233 | Mark Meredith 234 | Novell Inc. 235 | 1800 S. Novell Place 236 | Provo, UT 84606 237 | 238 | Phone: 801-861-2645 239 | EMail: mark_meredith@novell.com 240 | 241 | 242 | 243 | 244 | 245 | 246 | 247 | 248 | 249 | 250 | 251 | 252 | 253 | 254 | 255 | 256 | 257 | 258 | 259 | 260 | 261 | 262 | 263 | 264 | 265 | 266 | 267 | 268 | 269 | 270 | 271 | 272 | 273 | 274 | 275 | 276 | 277 | 278 | 279 | 280 | 281 | 282 | Meredith Informational [Page 5] 283 | 284 | RFC 3045 LDAP Root DSE to Display Vendor Information January 2001 285 | 286 | 287 | 10. Full Copyright Statement 288 | 289 | Copyright (C) The Internet Society (2001). All Rights Reserved. 290 | 291 | This document and translations of it may be copied and furnished to 292 | others, and derivative works that comment on or otherwise explain it 293 | or assist in its implementation may be prepared, copied, published 294 | and distributed, in whole or in part, without restriction of any 295 | kind, provided that the above copyright notice and this paragraph are 296 | included on all such copies and derivative works. However, this 297 | document itself may not be modified in any way, such as by removing 298 | the copyright notice or references to the Internet Society or other 299 | Internet organizations, except as needed for the purpose of 300 | developing Internet standards in which case the procedures for 301 | copyrights defined in the Internet Standards process must be 302 | followed, or as required to translate it into languages other than 303 | English. 304 | 305 | The limited permissions granted above are perpetual and will not be 306 | revoked by the Internet Society or its successors or assigns. 307 | 308 | This document and the information contained herein is provided on an 309 | "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 310 | TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 311 | BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 312 | HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 313 | MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 314 | 315 | Acknowledgement 316 | 317 | Funding for the RFC Editor function is currently provided by the 318 | Internet Society. 319 | 320 | 321 | 322 | 323 | 324 | 325 | 326 | 327 | 328 | 329 | 330 | 331 | 332 | 333 | 334 | 335 | 336 | 337 | 338 | Meredith Informational [Page 6] 339 | 340 | -------------------------------------------------------------------------------- /docs/rfc/ldap_extension_proposed_standard/rfc4526.txt: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | Network Working Group K. Zeilenga 8 | Request for Comments: 4526 OpenLDAP Foundation 9 | Category: Standards Track June 2006 10 | 11 | 12 | Lightweight Directory Access Protocol (LDAP) 13 | Absolute True and False Filters 14 | 15 | Status of This Memo 16 | 17 | This document specifies an Internet standards track protocol for the 18 | Internet community, and requests discussion and suggestions for 19 | improvements. Please refer to the current edition of the "Internet 20 | Official Protocol Standards" (STD 1) for the standardization state 21 | and status of this protocol. Distribution of this memo is unlimited. 22 | 23 | Copyright Notice 24 | 25 | Copyright (C) The Internet Society (2006). 26 | 27 | Abstract 28 | 29 | This document extends the Lightweight Directory Access Protocol 30 | (LDAP) to support absolute True and False filters based upon similar 31 | capabilities found in X.500 directory systems. The document also 32 | extends the String Representation of LDAP Search Filters to support 33 | these filters. 34 | 35 | Table of Contents 36 | 37 | 1. Background ......................................................1 38 | 2. Absolute True and False Filters .................................2 39 | 3. Security Considerations .........................................2 40 | 4. IANA Considerations .............................................3 41 | 5. References ......................................................3 42 | 5.1. Normative References .......................................3 43 | 5.2. Informative References .....................................3 44 | 45 | 1. Background 46 | 47 | The X.500 Directory Access Protocol (DAP) [X.511] supports absolute 48 | True and False assertions. An 'and' filter with zero elements always 49 | evaluates to True. An 'or' filter with zero elements always 50 | evaluates to False. These filters are commonly used when requesting 51 | DSA-specific Entries (DSEs) that do not necessarily have 52 | 'objectClass' attributes; that is, where "(objectClass=*)" may 53 | evaluate to False. 54 | 55 | 56 | 57 | 58 | Zeilenga Standards Track [Page 1] 59 | 60 | RFC 4526 LDAP Absolute True and False Filters June 2006 61 | 62 | 63 | Although LDAPv2 [RFC1777][RFC3494] placed no restriction on the 64 | number of elements in 'and' and 'or' filter sets, the LDAPv2 string 65 | representation [RFC1960][RFC3494] could not represent empty 'and' and 66 | 'or' filter sets. Due to this, absolute True or False filters were 67 | (unfortunately) eliminated from LDAPv3 [RFC4510]. 68 | 69 | This documents extends LDAPv3 to support absolute True and False 70 | assertions by allowing empty 'and' and 'or' in Search filters 71 | [RFC4511] and extends the filter string representation [RFC4515] to 72 | allow empty filter lists. 73 | 74 | It is noted that certain search operations, such as those used to 75 | retrieve subschema information [RFC4512], require use of particular 76 | filters. This document does not change these requirements. 77 | 78 | This feature is intended to allow a more direct mapping between DAP 79 | and LDAP (as needed to implement DAP-to-LDAP gateways). 80 | 81 | In this document, the key words "MUST", "MUST NOT", "REQUIRED", 82 | "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 83 | and "OPTIONAL" are to be interpreted as described in BCP 14 84 | [RFC2119]. 85 | 86 | 2. Absolute True and False Filters 87 | 88 | Implementations of this extension SHALL allow 'and' and 'or' choices 89 | with zero filter elements. 90 | 91 | An 'and' filter consisting of an empty set of filters SHALL evaluate 92 | to True. This filter is represented by the string "(&)". 93 | 94 | An 'or' filter consisting of an empty set of filters SHALL evaluate 95 | to False. This filter is represented by the string "(|)". 96 | 97 | Servers supporting this feature SHOULD publish the Object Identifier 98 | 1.3.6.1.4.1.4203.1.5.3 as a value of the 'supportedFeatures' 99 | [RFC4512] attribute in the root DSE. 100 | 101 | Clients supporting this feature SHOULD NOT use the feature unless 102 | they know that the server supports it. 103 | 104 | 3. Security Considerations 105 | 106 | The (re)introduction of absolute True and False filters is not 107 | believed to raise any new security considerations. 108 | 109 | Implementors of this (or any) LDAPv3 extension should be familiar 110 | with general LDAPv3 security considerations [RFC4510]. 111 | 112 | 113 | 114 | Zeilenga Standards Track [Page 2] 115 | 116 | RFC 4526 LDAP Absolute True and False Filters June 2006 117 | 118 | 119 | 4. IANA Considerations 120 | 121 | Registration of this feature has been completed by the IANA 122 | [RFC4520]. 123 | 124 | Subject: Request for LDAP Protocol Mechanism Registration Object 125 | Identifier: 1.3.6.1.4.1.4203.1.5.3 Description: True/False filters 126 | Person & email address to contact for further information: 127 | Kurt Zeilenga Usage: Feature Specification: 128 | RFC 4526 Author/Change Controller: IESG Comments: none 129 | 130 | This OID was assigned [ASSIGN] by OpenLDAP Foundation, under its 131 | IANA-assigned private enterprise allocation [PRIVATE], for use in 132 | this specification. 133 | 134 | 5. References 135 | 136 | 5.1. Normative References 137 | 138 | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 139 | Requirement Levels", BCP 14, RFC 2119, March 1997. 140 | 141 | [RFC4510] Zeilenga, K., Ed, "Lightweight Directory Access 142 | Protocol (LDAP): Technical Specification Road Map", RFC 143 | 4510, June 2006. 144 | 145 | [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access 146 | Protocol (LDAP): The Protocol", RFC 4511, June 2006. 147 | 148 | [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol 149 | (LDAP): Directory Information Models", RFC 4512, June 150 | 2006. 151 | 152 | [RFC4515] Smith, M., Ed. and T. Howes, "Lightweight Directory 153 | Access Protocol (LDAP): String Representation of Search 154 | Filters", RFC 4515, June 2006. 155 | 156 | 5.2. Informative References 157 | 158 | [RFC1777] Yeong, W., Howes, T., and S. Kille, "Lightweight 159 | Directory Access Protocol", RFC 1777, March 1995. 160 | 161 | [RFC1960] Howes, T., "A String Representation of LDAP Search 162 | Filters", RFC 1960, June 1996. 163 | 164 | [RFC3494] Zeilenga, K., "Lightweight Directory Access Protocol 165 | version 2 (LDAPv2) to Historic Status", RFC 3494, March 166 | 2003. 167 | 168 | 169 | 170 | Zeilenga Standards Track [Page 3] 171 | 172 | RFC 4526 LDAP Absolute True and False Filters June 2006 173 | 174 | 175 | [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority 176 | (IANA) Considerations for the Lightweight Directory 177 | Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006. 178 | 179 | [X.500] International Telecommunication Union - 180 | Telecommunication Standardization Sector, "The 181 | Directory -- Overview of concepts, models and 182 | services," X.500(1993) (also ISO/IEC 9594-1:1994). 183 | 184 | [X.501] International Telecommunication Union - 185 | Telecommunication Standardization Sector, "The 186 | Directory -- Models," X.501(1993) (also ISO/IEC 9594- 187 | 2:1994). 188 | 189 | [X.511] International Telecommunication Union - 190 | Telecommunication Standardization Sector, "The 191 | Directory: Abstract Service Definition", X.511(1993) 192 | (also ISO/IEC 9594-3:1993). 193 | 194 | [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations", 195 | http://www.openldap.org/foundation/oid-delegate.txt. 196 | 197 | [PRIVATE] IANA, "Private Enterprise Numbers", 198 | http://www.iana.org/assignments/enterprise-numbers. 199 | 200 | Author's Address 201 | 202 | Kurt D. Zeilenga 203 | OpenLDAP Foundation 204 | 205 | EMail: Kurt@OpenLDAP.org 206 | 207 | 208 | 209 | 210 | 211 | 212 | 213 | 214 | 215 | 216 | 217 | 218 | 219 | 220 | 221 | 222 | 223 | 224 | 225 | 226 | Zeilenga Standards Track [Page 4] 227 | 228 | RFC 4526 LDAP Absolute True and False Filters June 2006 229 | 230 | 231 | Full Copyright Statement 232 | 233 | Copyright (C) The Internet Society (2006). 234 | 235 | This document is subject to the rights, licenses and restrictions 236 | contained in BCP 78, and except as set forth therein, the authors 237 | retain all their rights. 238 | 239 | This document and the information contained herein are provided on an 240 | "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 241 | OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 242 | ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 243 | INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 244 | INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 245 | WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 246 | 247 | Intellectual Property 248 | 249 | The IETF takes no position regarding the validity or scope of any 250 | Intellectual Property Rights or other rights that might be claimed to 251 | pertain to the implementation or use of the technology described in 252 | this document or the extent to which any license under such rights 253 | might or might not be available; nor does it represent that it has 254 | made any independent effort to identify any such rights. Information 255 | on the procedures with respect to rights in RFC documents can be 256 | found in BCP 78 and BCP 79. 257 | 258 | Copies of IPR disclosures made to the IETF Secretariat and any 259 | assurances of licenses to be made available, or the result of an 260 | attempt made to obtain a general license or permission for the use of 261 | such proprietary rights by implementers or users of this 262 | specification can be obtained from the IETF on-line IPR repository at 263 | http://www.ietf.org/ipr. 264 | 265 | The IETF invites any interested party to bring to its attention any 266 | copyrights, patents or patent applications, or other proprietary 267 | rights that may cover technology that may be required to implement 268 | this standard. Please address the information to the IETF at 269 | ietf-ipr@ietf.org. 270 | 271 | Acknowledgement 272 | 273 | Funding for the RFC Editor function is provided by the IETF 274 | Administrative Support Activity (IASA). 275 | 276 | 277 | 278 | 279 | 280 | 281 | 282 | Zeilenga Standards Track [Page 5] 283 | 284 | -------------------------------------------------------------------------------- /docs/rfc/ldap_proposed_standard/errata/rfc2849-errata.txt: -------------------------------------------------------------------------------- 1 | RFC2849, "The LDAP Data Interchange Format (LDIF) - Technical Specification", June 2000 2 | Source of RFC: IETF - NON WORKING GROUP 3 | Area Assignment: app 4 | 5 | Errata ID: 2258 6 | 7 | Status: Held for Document Update 8 | Type: Technical 9 | 10 | Reported By: Flavio Poletti 11 | Date Reported: 2010-05-13 12 | Held for Document Update by: Peter Saint-Andre 13 | 14 | Throughout the document, when it says: 15 | 16 | Example 3: A file containing a base-64-encoded value 17 | 18 | version: 1 19 | dn: cn=Gern Jensen, ou=Product Testing, dc=airius, dc=com 20 | objectclass: top 21 | objectclass: person 22 | objectclass: organizationalPerson 23 | cn: Gern Jensen 24 | cn: Gern O Jensen 25 | sn: Jensen 26 | uid: gernj 27 | telephonenumber: +1 408 555 1212 28 | description:: V2hhdCBhIGNhcmVmdWwgcmVhZGVyIHlvdSBhcmUhICBUaGlzIHZhbHVl 29 | IGlzIGJhc2UtNjQtZW5jb2RlZCBiZWNhdXNlIGl0IGhhcyBhIGNvbnRyb2wgY2hhcmFjdG 30 | VyIGluIGl0IChhIENSKS4NICBCeSB0aGUgd2F5LCB5b3Ugc2hvdWxkIHJlYWxseSBnZXQg 31 | b3V0IG1vcmUu 32 | 33 | It should say: 34 | 35 | Example 3: A file containing a base-64-encoded value 36 | 37 | version: 1 38 | dn: cn=Gern Jensen, ou=Product Testing, dc=airius, dc=com 39 | objectclass: top 40 | objectclass: person 41 | objectclass: organizationalPerson 42 | cn: Gern Jensen 43 | cn: Gern O Jensen 44 | sn: Jensen 45 | uid: gernj 46 | telephonenumber: +1 408 555 1212 47 | description:: V2hhdCBhIGNhcmVmdWwgcmVhZGVyIHlvdSBhcmUhICBUaGlzIHZhbHVl 48 | IGlzIGJhc2UtNjQtZW5jb2RlZCBiZWNhdXNlIGl0IGhhcyBhIGNvbnRyb2wgY2hhcmFjdG 49 | VyIGluIGl0IChhIENSKS4NICBCeSB0aGUgd2F5LCB5b3Ugc2hvdWxkIHJlYWxseSBnZXQg 50 | b3V0IG1vcmUu 51 | 52 | Notes: 53 | 54 | There is no section numbering in this RFC, hence the "GLOBAL". 55 | 56 | Note 10 in "Notes on LDIF Syntax" says that base64-encoded values are subject to the same folding rules explained in Note 2. Note 2 requires folded lines to begin with a space character. 57 | 58 | This modification was introduced passing from draft-good-ldap-ldif to RFC 2849. 59 | 60 | Errata ID: 3646 61 | 62 | Status: Held for Document Update 63 | Type: Editorial 64 | 65 | Reported By: Boris Kleint 66 | Date Reported: 2013-06-11 67 | Held for Document Update by: Barry Leiba 68 | Date Held: 2013-08-21 69 | 70 | Section Note 4 says: 71 | 72 | Any dn or rdn that contains characters other than those 73 | defined as "SAFE-UTF8-CHAR", or begins with a character other 74 | than those defined as "SAFE-INIT-UTF8-CHAR", 75 | 76 | It should say: 77 | 78 | Any dn or rdn that contains characters other than those 79 | defined as "SAFE-CHAR", or begins with a character other 80 | than those defined as "SAFE-INIT-CHAR", 81 | 82 | Notes: 83 | 84 | This appears in note 4 of "Notes on LDIF Syntax". 85 | 86 | ---- Verifier notes ---- 87 | Note 4 has double text, one of which allows more than the other. But the ABNF 88 | doesn't have that ambiguity. This is really something that can only be fixed by 89 | revising the spec. It's simply not clear what the intent was. -------------------------------------------------------------------------------- /docs/rfc/ldap_proposed_standard/errata/rfc4511-errata.txt: -------------------------------------------------------------------------------- 1 | Errata ID: 75 2 | 3 | Status: Rejected 4 | Type: Technical 5 | 6 | Reported By: Alfred Hoenes 7 | Date Reported: 2006-06-23 8 | Rejected by: Jim Sermersheim 9 | Date Rejected: 2006-07-03 10 | 11 | 12 | (2) Typo 13 | 14 | Section 2, on page 4, contains the paragraph: 15 | v 16 | | The term "SASL layer" refers to Simply Authentication and Security 17 | Layer (SASL) services used in providing security services, as well as 18 | associations established by these services. 19 | 20 | It should say: 21 | v 22 | | The term "SASL layer" refers to Simple Authentication and Security 23 | Layer (SASL) services used in providing security services, as well as 24 | associations established by these services. 25 | 26 | 27 | (3) Misrepresented relationship between ISO 10646 and Unicode 28 | 29 | Section 4.1.2 unfortunately has not corrected a misconception 30 | initially spelled out in RFC 2251. 31 | 32 | The first paragraph of Section 4.1.2, on page 7, says: 33 | 34 | The LDAPString is a notational convenience to indicate that, although 35 | strings of LDAPString type encode as ASN.1 OCTET STRING types, the 36 | | [ISO10646] character set (a superset of [Unicode]) is used, encoded 37 | following the UTF-8 [RFC3629] algorithm. [...] 38 | 39 | The (..) enclosed note on the relationship of ISO 10646 and Unicode 40 | is *not* appropriate, as far as I know: 41 | 42 | Unicode covers exactly the same character repertoire as ISO 10646, 43 | but it *adds* a lot of *semantics* to ISO 10646. 44 | The character repertoire synchronization between ISO 10646 and 45 | Unicode is said to hold since 1993, and it is promised for all 46 | future updates. 47 | (Details can be found in Section 1.4 and Appendix C of 48 | The Unicode Standard (book and online version), verbatim 49 | identical in the Unicode 3.0 and Unicode 4.0 versions.) 50 | 51 | In particular, this congruence holds for Unicode 3.2.0 52 | (and the coordinated edition of ISO 10646) that has been 53 | made the invariable base for the new LDAP specs. 54 | 55 | Therefore, the above sentence should perhaps better be 56 | corrected to say: 57 | 58 | The LDAPString is a notational convenience to indicate that, although 59 | strings of LDAPString type encode as ASN.1 OCTET STRING types, the 60 | | [ISO10646] character set (as detailed in [Unicode]) is used, encoded 61 | following the UTF-8 [RFC3629] algorithm. [...] 62 | 63 | (or similar). 64 | 65 | 66 | (4) Typo (word omission) 67 | 68 | The 3rd paragraph of Section 4.2.2, on page 18, says: 69 | 70 | If the client receives a BindResponse where the resultCode is set to 71 | protocolError, it is to assume that the server does not support this 72 | | version of LDAP. While the client may be able proceed with another 73 | version of this protocol (which may or may not require closing and 74 | re-establishing the transport connection), how to proceed with 75 | another version of this protocol is beyond the scope of this 76 | document. Clients that are unable or unwilling to proceed SHOULD 77 | terminate the LDAP session. 78 | 79 | It should say: 80 | vvvv 81 | | [...]. While the client may be able to proceed with 82 | another version of this protocol (which may or may not require 83 | closing and re-establishing the transport connection), how to proceed 84 | with another version of this protocol is beyond the scope of this 85 | document. [...] 86 | 87 | 88 | Items (2)..(4) above might be considered for an Errata Note 89 | to be posted to the RFC Editor's "RFC Errata" web pages. 90 | I propose that you submit an Author's Errata Note, based on the 91 | material presented above, and/or choosing alternate text for (3). 92 | Notes: 93 | 94 | In any case, these items should be noted for future reference, 95 | whenever once another revision of these RFCs is to be produced, 96 | e.g., for advancement on the Standards Track. 97 | 98 | [note: (1) contained general comments and has been removed.] 99 | 100 | Author saving on file for possible revision. 101 | 102 | from pending -------------------------------------------------------------------------------- /docs/rfc/ldap_proposed_standard/errata/rfc4512-errata.txt: -------------------------------------------------------------------------------- 1 | Errata ID: 74 2 | 3 | Status: Held for Document Update 4 | Type: Editorial 5 | 6 | Reported By: Alfred Hoenes 7 | Date Reported: 2006-07-07 8 | Held for Document Update by: Alexey Melnikov 9 | Date Held: 2010-05-21 10 | 11 | 12 | (E1) text truncation (?) 13 | 14 | Apparently, the text of the first paragraph of Section 3.2, 15 | on page 18 of RFC 4512, has been truncated inadvertently. 16 | The RFC text says: 17 | 18 | A subentry is a "special sort of entry, known by the Directory, used 19 | to hold information associated with a subtree or subtree refinement" 20 | | [X.501]. Subentries are used in Directory to hold for administrative 21 | | and operational purposes as defined in [X.501]. Their use in LDAP is 22 | detailed in [RFC3672]. 23 | 24 | I suspect that it should in fact say: 25 | 26 | A subentry is a "special sort of entry, known by the Directory, used 27 | to hold information associated with a subtree or subtree refinement" 28 | | [X.501]. Subentries are used in the Directory to hold attributes for 29 | | administrative and operational purposes as defined in [X.501]. Their 30 | use in LDAP is detailed in [RFC3672]. 31 | 32 | 33 | (E2) typo 34 | 35 | In Section 4.1.7.1, near the bottom of page 30, the explanation, 36 | 37 | FORM is specifies the name form associated with this DIT structure 38 | rule; 39 | 40 | should say: 41 | 42 | | FORM specifies the name form associated with this DIT structure 43 | rule; 44 | 45 | 46 | (E3) typo 47 | 48 | The first paragraph of Section 5.1, on page 36, says: 49 | 50 | An LDAP server SHALL provide information about itself and other 51 | information that is specific to each server. This is represented as 52 | a group of attributes located in the root DSE, which is named with 53 | | the DN with zero RDNs (whose [RFC4514] representation is as the 54 | zero-length string). 55 | 56 | It should say: 57 | 58 | An LDAP server SHALL provide information about itself and other 59 | information that is specific to each server. This is represented as 60 | a group of attributes located in the root DSE, which is named with 61 | | the DN with zero RDNs (whose [RFC4514] representation is the zero- 62 | length string). 63 | 64 | 65 | (E4) word omission 66 | 67 | The second paragraph of Section A.2.1, on page 49, says: 68 | 69 | The syntax was changed to disallow semicolon (U+003B) 70 | characters in order to appear to be consistent its natural language 71 | specification "descr is the syntactic representation of an object 72 | descriptor, which consists of letters and digits, starting with a 73 | letter". In a related change, the statement "an AttributeDescription 74 | can be used as the value in a NAME part of an 75 | AttributeTypeDescription" was deleted. RFC 2252 provided no 76 | specification of the semantics of attribute options appearing in NAME 77 | fields. 78 | 79 | It should say: 80 | 81 | The syntax was changed to disallow semicolon (U+003B) 82 | | characters in order to appear to be consistent with its natural 83 | language specification "descr is the syntactic representation of an 84 | object descriptor, which consists of letters and digits, starting 85 | with a letter". 86 | In a related change, the statement "an AttributeDescription can be 87 | used as the value in a NAME part of an AttributeTypeDescription" was 88 | deleted. RFC 2252 provided no specification of the semantics of 89 | attribute options appearing in NAME fields. 90 | 91 | 92 | And these are my side notes for future consideration. 93 | There are a couple of missing articles in the RFC text. 94 | I have noted the following places: 95 | 96 | 97 | (N1) 98 | 99 | In Section 4.1.1, on page 24, the explanation, 100 | 101 | where: 102 | is object identifier assigned to this object class; 103 | [...] 104 | 105 | should better say: 106 | 107 | where: 108 | | is the object identifier assigned to this object 109 | class; 110 | [...] 111 | 112 | 113 | (N2) 114 | 115 | In Section 4.1.2, 116 | 117 | a) on page 25, the literally same correction as (N1) applies, and 118 | 119 | b) the explanation: 120 | 121 | SYNTAX identifies value syntax by object identifier and may suggest 122 | a minimum upper bound; 123 | 124 | should better say: 125 | 126 | | SYNTAX identifies the value syntax by its object identifier and may 127 | suggest a minimum upper bound; 128 | 129 | c) Finally, on top of page 26, the paragraph, 130 | 131 | If SUP field is provided, the EQUALITY, ORDERING, and SUBSTRING 132 | fields, if not specified, take their value from the supertype. 133 | 134 | should better say: 135 | 136 | | If the SUP field is provided, the EQUALITY, ORDERING, and SUBSTRING 137 | fields, if not specified, take their value from the supertype. 138 | 139 | 140 | (N3) 141 | 142 | In Section 4.1.3, on page 27, -- similarly to (N1) -- 143 | the explanation, 144 | 145 | where: 146 | is object identifier assigned to this matching rule; 147 | [...] 148 | 149 | should better say: 150 | 151 | where: 152 | is the object identifier assigned to this matching 153 | rule; 154 | [...] 155 | 156 | 157 | (N4) 158 | 159 | In Section 4.1.7.2, on page 31, -- again like in (N1) -- 160 | the explanation, 161 | 162 | where: 163 | is object identifier that identifies this name form; 164 | [...] 165 | 166 | should better say: 167 | 168 | where: 169 | is the object identifier that identifies this name 170 | form; 171 | [...] 172 | 173 | 174 | (N5) 175 | 176 | The final sentence of Section 4.2, i.e. the 3rd paragraph on page 33, 177 | says: 178 | 179 | The following subsections provide attribute type definitions for each 180 | of schema definition attribute types. 181 | 182 | It should say: 183 | 184 | The following subsections provide attribute type definitions for each 185 | | of the schema definition attribute types. 186 | Notes: 187 | 188 | Source: apps 189 | 190 | Errata ID: 2281 191 | 192 | Status: Held for Document Update 193 | Type: Editorial 194 | 195 | Reported By: Alfred Hoenes 196 | Date Reported: 2006-07-07 197 | Held for Document Update by: Peter Saint-Andre 198 | Date Held: 2010-05-21 199 | Section A.3 says: 200 | 201 | The second paragraph of Section A.3, at the bottom of page 50, says: 202 | 203 | Section 5.1 of RFC 2256 provided the definition of the 'objectClass' 204 | attribute type. This was integrated into Section 2.4.1 of this 205 | document. The statement "One of the values is either 'top' or 206 | 'alias'" was replaced with statement that one of the values is 'top' 207 | as entries belonging to 'alias' also belong to 'top'. 208 | 209 | It should say: 210 | 211 | Section 5.1 of RFC 2256 provided the definition of the 'objectClass' 212 | | attribute type. This was integrated into Section 3.3 of this 213 | document. The statement "One of the values is either 'top' or 214 | 'alias'" was replaced with statement that one of the values is 'top' 215 | as entries belonging to 'alias' also belong to 'top'. 216 | 217 | Notes: 218 | 219 | Apparently, 'Section 3.3' would have been much more appropriate than 220 | 'Section 2.4.1'. 221 | 222 | Source: apps -------------------------------------------------------------------------------- /docs/rfc/ldap_proposed_standard/errata/rfc4514-errata.txt: -------------------------------------------------------------------------------- 1 | Errata ID: 73 2 | 3 | Status: Held for Document Update 4 | Type: Editorial 5 | 6 | Reported By: Alfred Hoenes 7 | Date Reported: 2006-07-07 8 | Held for Document Update by: Alexey Melnikov 9 | Date Held: 2010-05-21 10 | Section 4 says: 11 | 12 | This example shows the method of escaping of a special characters 13 | appearing in a common name: 14 | It should say: 15 | 16 | This example shows the method of escaping of special characters 17 | appearing in a common name: 18 | Notes: 19 | 20 | Source: apps -------------------------------------------------------------------------------- /docs/rfc/ldap_proposed_standard/errata/rfc4515-errata.txt: -------------------------------------------------------------------------------- 1 | Errata ID: 72 2 | 3 | Status: Held for Document Update 4 | Type: Editorial 5 | 6 | Reported By: Alfred Hoenes 7 | Date Reported: 2006-06-23 8 | Held for Document Update by: Alexey Melnikov 9 | Date Held: 2010-05-21 10 | Section 4 says: 11 | 12 | The first example shows use of the matching rule "caseExactMatch." 13 | It should say: 14 | 15 | The first example shows use of the matching rule "caseExactMatch". 16 | Notes: 17 | 18 | Source: apps 19 | 20 | Errata ID: 840 21 | 22 | Status: Held for Document Update 23 | Type: Editorial 24 | 25 | Reported By: Alfred Hoenes 26 | Date Reported: 2006-06-23 27 | Held for Document Update by: Alexey Melnikov 28 | Date Held: 2010-05-21 29 | Section 2 says: 30 | 31 | The ASN.1 term, `AttributeValue`, has been replaced by 32 | `AssertionValue` wherever it was used previously. 33 | Hence, in Section 2 (on page 3) of RFC 4515 34 | 35 | - the ASN.1 line 36 | 37 | AttributeValue ::= OCTET STRING 38 | 39 | is not needed any more and might have been omitted, and 40 | 41 | - in the subsequent explanation, the sentence, 42 | 43 | [...] The AttributeValue and AssertionValue OCTET STRING have 44 | the form defined in [RFC4517]. [...] 45 | 46 | might have been shortened to say: 47 | 48 | [...] The AssertionValue OCTET STRING has the form defined ib 49 | [RFC4517]. [...] 50 | Notes: 51 | 52 | Source: apps -------------------------------------------------------------------------------- /docs/rfc/ldap_proposed_standard/errata/rfc4516-errata.txt: -------------------------------------------------------------------------------- 1 | Errata ID: 71 2 | 3 | Status: Held for Document Update 4 | Type: Editorial 5 | 6 | Reported By: Alfred Hoenes 7 | Date Reported: 2006-06-23 8 | Held for Document Update by: Alexey Melnikov 9 | Date Held: 2010-05-21 10 | Section Appendix A.2 says: 11 | 12 | Changed the text indicate that RFC 2255 is replaced ... 13 | It should say: 14 | 15 | Changed the text to indicate that RFC 2255 is replaced ... 16 | Notes: -------------------------------------------------------------------------------- /docs/rfc/ldap_proposed_standard/errata/rfc4518-errata.txt: -------------------------------------------------------------------------------- 1 | Errata ID: 860 2 | 3 | Status: Verified 4 | Type: Technical 5 | 6 | Reported By: Stephane PERBELLINI 7 | Date Reported: 2007-02-23 8 | Verifier Name: Kurt Zeilenga 9 | Date Verified: 2007-02-23 10 | Section 2.2 says: 11 | 12 | COMBINING GRAPHEME JOINER (U+034F) and VARIATION SELECTORs 13 | (U+180B-180D, FF00-FE0F) code points are also mapped to nothing. 14 | It should say: 15 | 16 | COMBINING GRAPHEME JOINER (U+034F) and VARIATION SELECTORs 17 | (U+180B-180D, FE00-FE0F) code points are also 18 | Notes: 19 | 20 | FF00-FE0F should be FE00-FE0F 21 | 22 | from pending 23 | 24 | Errata ID: 1757 25 | 26 | Status: Verified 27 | Type: Technical 28 | 29 | Reported By: Steven Legg 30 | Date Reported: 2009-04-05 31 | Verifier Name: Alexey Melnikov 32 | Date Verified: 2010-05-20 33 | Section 2.6.1 says: 34 | 35 | Otherwise, the following steps are taken: 36 | It should say: 37 | 38 | Otherwise, the following steps are taken: 39 | 40 | - Any inner (non-empty) sequence of space characters is replaced 41 | with exactly two SPACE characters; 42 | Errata ID: 1758 43 | 44 | Status: Verified 45 | Type: Technical 46 | 47 | Reported By: Steven Legg 48 | Date Reported: 2009-04-05 49 | Verifier Name: Alexey Melnikov 50 | Date Verified: 2010-05-20 51 | Section 2.6.1 says: 52 | 53 | As an any or final substring, the same input would result in "foobar". 54 | It should say: 55 | 56 | As an any or final substring, the same input would result in "foobar". -------------------------------------------------------------------------------- /docs/rfc/ldap_proposed_standard/errata/rfc4519-errata.txt: -------------------------------------------------------------------------------- 1 | Errata ID: 70 2 | 3 | Status: Held for Document Update 4 | Type: Editorial 5 | 6 | Reported By: Alfred Hoenes 7 | Date Reported: 2006-07-07 8 | Held for Document Update by: Alexey Melnikov 9 | Appendix A says: 10 | 11 | 18. Removed Section 2.4 (Source). Replaced the source table with 12 | explicit references for each definition. 13 | It should say: 14 | 15 | 18. Removed Section 4 (Source). Replaced the source table with 16 | explicit references for each definition. 17 | Status: Rejected (1) 18 | 19 | RFC4519, "Lightweight Directory Access Protocol (LDAP): Schema for User Applications", June 2006 20 | 21 | Source of RFC: ldapbis (app) 22 | Errata ID: 1761 23 | 24 | Status: Rejected 25 | Type: Technical 26 | 27 | Reported By: Fotis Georgatos 28 | Date Reported: 2009-04-10 29 | Rejected by: Alexey Melnikov 30 | Date Rejected: 2010-09-02 31 | Section 3.10 says: 32 | 33 | 3.10. 'organizationalRole' 34 | 35 | The 'organizationalRole' object class is the basis of an entry that 36 | represents a job, function, or position in an organization. 37 | (Source: X.521 [X.521]) 38 | 39 | ( 2.5.6.8 NAME 'organizationalRole' 40 | SUP top 41 | STRUCTURAL 42 | MUST cn 43 | MAY ( x121Address $ registeredAddress $ destinationIndicator $ 44 | preferredDeliveryMethod $ telexNumber $ 45 | teletexTerminalIdentifier $ telephoneNumber $ 46 | internationalISDNNumber $ facsimileTelephoneNumber $ 47 | seeAlso $ roleOccupant $ preferredDeliveryMethod $ 48 | street $ postOfficeBox $ postalCode $ postalAddress $ 49 | physicalDeliveryOfficeName $ ou $ st $ l $ 50 | description ) ) 51 | It should say: 52 | 53 | 3.10. 'organizationalRole' 54 | 55 | The 'organizationalRole' object class is the basis of an entry that 56 | represents a job, function, or position in an organization. 57 | (Source: X.521 [X.521]) 58 | 59 | ( 2.5.6.8 NAME 'organizationalRole' 60 | SUP top 61 | STRUCTURAL 62 | MUST cn 63 | MAY ( x121Address $ registeredAddress $ destinationIndicator $ 64 | preferredDeliveryMethod $ telexNumber $ 65 | teletexTerminalIdentifier $ telephoneNumber $ 66 | internationalISDNNumber $ facsimileTelephoneNumber $ 67 | seeAlso $ roleOccupant $ 68 | street $ postOfficeBox $ postalCode $ postalAddress $ 69 | physicalDeliveryOfficeName $ ou $ st $ l $ 70 | description ) ) 71 | Notes: 72 | 73 | Any object classes that include the preferredDeliveryMethod twice should be either redefined, by including it only once, OR provide an explicit reference about how it should be interpreted by the implementations; such examples are: 74 | organizationalRole (3.10) 75 | residentialPerson (3.13) 76 | 77 | Note that this error has been affecting OpenLDAP implementations at least 78 | since year 2002; with the side-effect that imported ldif data would disappear: 79 | http://www.openldap.org/lists/ietf-ldapbis/200207/msg00002.html 80 | It is surprising that it has remained unaddressed during so many years. 81 | 82 | Also, Kurt Zeilinga has proposed to adopt the following (sufficient) rule: 83 | "that implementations SHOULD be (and are) ignoring the redundant listing". 84 | --VERIFIER NOTES-- 85 | Kurt Zeilenga said: 86 | 87 | This issue was raised to the LDAPbis WG at the time it was working on the I-D which became RFC 4519 yet RFC 4519 did not include the suggested change. Simply put, there was insufficient support of the suggested change at that time. 88 | 89 | The change is also bad in that in removes one of the examples of multiple listed attributes, a rarely used but still valid (for historical reasons) of X.500/LDAP schema descriptions, and hence may lead to implementations not supporting this feature and by doing so causing interop problems. -------------------------------------------------------------------------------- /docs/rfc/ldap_proposed_standard/rfc3673.txt: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | Network Working Group K. Zeilenga 8 | Request for Comments: 3673 OpenLDAP Foundation 9 | Category: Standards Track December 2003 10 | 11 | 12 | Lightweight Directory Access Protocol version 3 (LDAPv3): 13 | All Operational Attributes 14 | 15 | Status of this Memo 16 | 17 | This document specifies an Internet standards track protocol for the 18 | Internet community, and requests discussion and suggestions for 19 | improvements. Please refer to the current edition of the "Internet 20 | Official Protocol Standards" (STD 1) for the standardization state 21 | and status of this protocol. Distribution of this memo is unlimited. 22 | 23 | Copyright Notice 24 | 25 | Copyright (C) The Internet Society (2003). All Rights Reserved. 26 | 27 | Abstract 28 | 29 | The Lightweight Directory Access Protocol (LDAP) supports a mechanism 30 | for requesting the return of all user attributes but not all 31 | operational attributes. This document describes an LDAP extension 32 | which clients may use to request the return of all operational 33 | attributes. 34 | 35 | 1. Overview 36 | 37 | X.500 [X.500] provides a mechanism for clients to request all 38 | operational attributes be returned with entries provided in response 39 | to a search operation. This mechanism is often used by clients to 40 | discover which operational attributes are present in an entry. 41 | 42 | This documents extends the Lightweight Directory Access Protocol 43 | (LDAP) [RFC3377] to provide a simple mechanism which clients may use 44 | to request the return of all operational attributes. The mechanism 45 | is designed for use with existing general purpose LDAP clients 46 | (including web browsers which support LDAP URLs) and existing LDAP 47 | APIs. 48 | 49 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 50 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 51 | document are to be interpreted as described in BCP 14 [RFC2119]. 52 | 53 | 54 | 55 | 56 | 57 | 58 | Zeilenga Standards Track [Page 1] 59 | 60 | RFC 3673 LDAPv3: All Operational Attributes December 2003 61 | 62 | 63 | 2. All Operational Attributes 64 | 65 | The presence of the attribute description "+" (ASCII 43) in the list 66 | of attributes in a Search Request [RFC2251] SHALL signify a request 67 | for the return of all operational attributes. 68 | 69 | As with all search requests, client implementors should note that 70 | results may not include all requested attributes due to access 71 | controls or other restrictions. Client implementors should also note 72 | that certain operational attributes may be returned only if requested 73 | by name even when "+" is present. This is because some operational 74 | attributes are very expensive to return. 75 | 76 | Servers supporting this feature SHOULD publish the Object Identifier 77 | 1.3.6.1.4.1.4203.1.5.1 as a value of the 'supportedFeatures' 78 | [RFC3674] attribute in the root DSE. 79 | 80 | 3. Interoperability Considerations 81 | 82 | This mechanism is specifically designed to allow users to request all 83 | operational attributes using existing LDAP clients. In particular, 84 | the mechanism is designed to be compatible with existing general 85 | purpose LDAP clients including those supporting LDAP URLs [RFC2255]. 86 | 87 | The addition of this mechanism to LDAP is not believed to cause any 88 | significant interoperability issues (this has been confirmed through 89 | testing). Servers which have yet to implement this specification 90 | should ignore the "+" as an unrecognized attribute description per 91 | [RFC2251, Section 4.5.1]. From the client's perspective, a server 92 | which does not return all operational attributes when "+" is 93 | requested should be viewed as having other restrictions. 94 | 95 | It is also noted that this mechanism is believed to require no 96 | modification of existing LDAP APIs. 97 | 98 | 4. Security Considerations 99 | 100 | This document provides a general mechanism which clients may use to 101 | discover operational attributes. Prior to the introduction of this 102 | mechanism, operational attributes were only returned when requested 103 | by name. Some might have viewed this as obscurity feature. However, 104 | this feature offers a false sense of security as the attributes were 105 | still transferable. 106 | 107 | Implementations SHOULD implement appropriate access controls 108 | mechanisms to restricts access to operational attributes. 109 | 110 | 111 | 112 | 113 | 114 | Zeilenga Standards Track [Page 2] 115 | 116 | RFC 3673 LDAPv3: All Operational Attributes December 2003 117 | 118 | 119 | 5. IANA Considerations 120 | 121 | This document uses the OID 1.3.6.1.4.1.4203.1.5.1 to identify the 122 | feature described above. This OID was assigned [ASSIGN] by OpenLDAP 123 | Foundation, under its IANA-assigned private enterprise allocation 124 | [PRIVATE], for use in this specification. 125 | 126 | Registration of this feature has been completed by IANA [RFC3674], 127 | [RFC3383]. 128 | 129 | Subject: Request for LDAP Protocol Mechanism Registration 130 | 131 | Object Identifier: 1.3.6.1.4.1.4203.1.5.1 132 | 133 | Description: All Op Attrs 134 | 135 | Person & email address to contact for further information: 136 | Kurt Zeilenga 137 | 138 | Usage: Feature 139 | 140 | Specification: RFC3673 141 | 142 | Author/Change Controller: IESG 143 | 144 | Comments: none 145 | 146 | 6. Acknowledgment 147 | 148 | The "+" mechanism is believed to have been first suggested by Bruce 149 | Greenblatt in a November 1998 post to the IETF LDAPext Working Group 150 | mailing list. 151 | 152 | 7. Intellectual Property Statement 153 | 154 | The IETF takes no position regarding the validity or scope of any 155 | intellectual property or other rights that might be claimed to 156 | pertain to the implementation or use of the technology described in 157 | this document or the extent to which any license under such rights 158 | might or might not be available; neither does it represent that it 159 | has made any effort to identify any such rights. Information on the 160 | IETF's procedures with respect to rights in standards-track and 161 | standards-related documentation can be found in BCP-11. Copies of 162 | claims of rights made available for publication and any assurances of 163 | licenses to be made available, or the result of an attempt made to 164 | obtain a general license or permission for the use of such 165 | proprietary rights by implementors or users of this specification can 166 | be obtained from the IETF Secretariat. 167 | 168 | 169 | 170 | Zeilenga Standards Track [Page 3] 171 | 172 | RFC 3673 LDAPv3: All Operational Attributes December 2003 173 | 174 | 175 | The IETF invites any interested party to bring to its attention any 176 | copyrights, patents or patent applications, or other proprietary 177 | rights which may cover technology that may be required to practice 178 | this standard. Please address the information to the IETF Executive 179 | Director. 180 | 181 | 8. References 182 | 183 | 8.1. Normative References 184 | 185 | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 186 | Requirement Levels", BCP 14, RFC 2119, March 1997. 187 | 188 | [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory 189 | Access Protocol (v3)", RFC 2251, December 1997. 190 | 191 | [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access 192 | Protocol (v3): Technical Specification", RFC 3377, 193 | September 2002. 194 | 195 | [RFC3674] Zeilenga, K., "Feature Discovery in Lightweight Directory 196 | Access Protocol (LDAP)", RFC 3674, December 2003. 197 | 198 | 8.2. Informative References 199 | 200 | [RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255, 201 | December 1997. 202 | 203 | [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) 204 | Considerations for the Lightweight Directory Access 205 | Protocol (LDAP)", BCP 64, RFC 3383, September 2002. 206 | 207 | [X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts, 208 | Models and Service", 1993. 209 | 210 | [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations", 211 | http://www.openldap.org/foundation/oid-delegate.txt. 212 | 213 | [PRIVATE] IANA, "Private Enterprise Numbers", 214 | http://www.iana.org/assignments/enterprise-numbers. 215 | 216 | 9. Author's Address 217 | 218 | Kurt D. Zeilenga 219 | OpenLDAP Foundation 220 | 221 | EMail: Kurt@OpenLDAP.org 222 | 223 | 224 | 225 | 226 | Zeilenga Standards Track [Page 4] 227 | 228 | RFC 3673 LDAPv3: All Operational Attributes December 2003 229 | 230 | 231 | 10. Full Copyright Statement 232 | 233 | Copyright (C) The Internet Society (2003). All Rights Reserved. 234 | 235 | This document and translations of it may be copied and furnished to 236 | others, and derivative works that comment on or otherwise explain it 237 | or assist in its implementation may be prepared, copied, published 238 | and distributed, in whole or in part, without restriction of any 239 | kind, provided that the above copyright notice and this paragraph are 240 | included on all such copies and derivative works. However, this 241 | document itself may not be modified in any way, such as by removing 242 | the copyright notice or references to the Internet Society or other 243 | Internet organizations, except as needed for the purpose of 244 | developing Internet standards in which case the procedures for 245 | copyrights defined in the Internet Standards process must be 246 | followed, or as required to translate it into languages other than 247 | English. 248 | 249 | The limited permissions granted above are perpetual and will not be 250 | revoked by the Internet Society or its successors or assignees. 251 | 252 | This document and the information contained herein is provided on an 253 | "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 254 | TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 255 | BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 256 | HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 257 | MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 258 | 259 | Acknowledgement 260 | 261 | Funding for the RFC Editor function is currently provided by the 262 | Internet Society. 263 | 264 | 265 | 266 | 267 | 268 | 269 | 270 | 271 | 272 | 273 | 274 | 275 | 276 | 277 | 278 | 279 | 280 | 281 | 282 | Zeilenga Standards Track [Page 5] 283 | 284 | -------------------------------------------------------------------------------- /docs/rfc/ldap_proposed_standard/rfc5020.txt: -------------------------------------------------------------------------------- 1 | Network Working Group K. Zeilenga 2 | Request for Comments: 5020 Isode Limited 3 | Category: Standards Track August 2007 4 | 5 | 6 | The Lightweight Directory Access Protocol (LDAP) entryDN 7 | Operational Attribute 8 | 9 | Status of This Memo 10 | 11 | This document specifies an Internet standards track protocol for the 12 | Internet community, and requests discussion and suggestions for 13 | improvements. Please refer to the current edition of the "Internet 14 | Official Protocol Standards" (STD 1) for the standardization state 15 | and status of this protocol. Distribution of this memo is unlimited. 16 | 17 | Copyright Notice 18 | 19 | Copyright (C) The IETF Trust (2007). 20 | 21 | Abstract 22 | 23 | This document describes the Lightweight Directory Access Protocol 24 | (LDAP) / X.500 'entryDN' operational attribute. The attribute 25 | provides a copy of the entry's distinguished name for use in 26 | attribute value assertions. 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | Zeilenga Standards Track [Page 1] 53 | 54 | RFC 5020 LDAP entryDN August 2007 55 | 56 | 57 | 1. Background and Intended Use 58 | 59 | In X.500 Directory Services [X.501], such as those accessible using 60 | the Lightweight Directory Access Protocol (LDAP) [RFC4510], an entry 61 | is identified by its distinguished name (DN) [RFC4512]. However, as 62 | an entry's DN is not an attribute of the entry, it is not possible to 63 | perform attribute value assertions [RFC4511] against it. 64 | 65 | This document describes the 'entryDN' operational attribute which 66 | holds a copy of the entry's distinguished name. This attribute may 67 | be used in search filters. For instance, searching the subtree 68 | with the filter: 69 | 70 | (entryDN:componentFilterMatch:=or:{ 71 | item:{ component "3", rule rdnMatch, value "ou=A" }, 72 | item:{ component "3", rule rdnMatch, value "ou=B" } }) 73 | 74 | would return entries in the subtree and 75 | entries in subtree , but would not return any 76 | other entries in the subtree . 77 | 78 | In the above paragraph, DNs are presented using the string 79 | representation defined in [RFC4514], and the example search filter is 80 | presented using the string representation defined in [RFC4515] with 81 | whitespace (line breaks and indentation) added to improve 82 | readability. The 'componentFilterMatch' and 'rdnMatch' rules are 83 | specified in [RFC3687]. 84 | 85 | Schema definitions are provided using LDAP description formats 86 | [RFC4512]. Definitions provided here are formatted (line wrapped) 87 | for readability. 88 | 89 | 2. 'entryDN' Operational Attribute 90 | 91 | The 'entryDN' operational attribute provides a copy of the entry's 92 | current DN. 93 | 94 | The following is an LDAP attribute type description suitable for 95 | publication in subschema subentries. 96 | 97 | ( 1.3.6.1.1.20 NAME 'entryDN' 98 | DESC 'DN of the entry' 99 | EQUALITY distinguishedNameMatch 100 | SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 101 | SINGLE-VALUE 102 | NO-USER-MODIFICATION 103 | USAGE directoryOperation ) 104 | 105 | 106 | 107 | 108 | Zeilenga Standards Track [Page 2] 109 | 110 | RFC 5020 LDAP entryDN August 2007 111 | 112 | 113 | Note that the DN of the entry cannot be modified through this 114 | attribute. 115 | 116 | 3. Security Considerations 117 | 118 | As this attribute only provides an additional mechanism to access an 119 | entry's DN, the introduction of this attribute is not believed to 120 | introduce new security considerations. 121 | 122 | 4. IANA Considerations 123 | 124 | 4.1. Object Identifier Registration 125 | 126 | IANA has registered (upon Standards Action) an LDAP Object Identifier 127 | [RFC4520] for use in this document. 128 | 129 | Subject: Request for LDAP OID Registration 130 | Person & email address to contact for further information: 131 | Kurt Zeilenga 132 | Specification: RFC 5020 133 | Author/Change Controller: IESG 134 | Comments: 135 | Identifies the 'entryDN' attribute type 136 | 137 | 4.2. 'entryDN' Descriptor Registration 138 | 139 | IANA has registered (upon Standards Action) the LDAP 'entryDN' 140 | descriptor [RFC4520]. 141 | 142 | Subject: Request for LDAP Descriptor Registration 143 | Descriptor (short name): entryDN 144 | Object Identifier: 1.3.6.1.1.20 145 | Person & email address to contact for further information: 146 | Kurt Zeilenga 147 | Usage: Attribute Type 148 | Specification: RFC 5020 149 | Author/Change Controller: IESG 150 | 151 | 152 | 153 | 154 | 155 | 156 | 157 | 158 | 159 | 160 | 161 | 162 | 163 | 164 | Zeilenga Standards Track [Page 3] 165 | 166 | RFC 5020 LDAP entryDN August 2007 167 | 168 | 169 | 5. References 170 | 171 | 5.1. Normative References 172 | 173 | [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol 174 | (LDAP): Technical Specification Road Map", RFC 4510, June 175 | 2006. 176 | 177 | [RFC4512] Zeilenga, K., Ed., "Lightweight Directory Access Protocol 178 | (LDAP): Directory Information Models", RFC 4512, June 179 | 2006. 180 | 181 | [X.501] International Telecommunication Union - Telecommunication 182 | Standardization Sector, "The Directory -- Models," 183 | X.501(1993) (also ISO/IEC 9594-2:1994). 184 | 185 | 5.2. Informative References 186 | 187 | [RFC3687] Legg, S., "Lightweight Directory Access Protocol (LDAP) 188 | and X.500 Component Matching Rules", RFC 3687, February 189 | 2004. 190 | 191 | [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access 192 | Protocol (LDAP): The Protocol", RFC 4511, June 2006. 193 | 194 | [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol 195 | (LDAP): String Representation of Distinguished Names", 196 | RFC 4514, June 2006. 197 | 198 | [RFC4515] Smith, M., Ed., and T. Howes, "Lightweight Directory 199 | Access Protocol (LDAP): String Representation of Search 200 | Filters", RFC 4515, June 2006. 201 | 202 | [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) 203 | Considerations for the Lightweight Directory Access 204 | Protocol (LDAP)", BCP 64, RFC 4520, June 2006. 205 | 206 | Author's Address 207 | 208 | Kurt D. Zeilenga 209 | Isode Limited 210 | 211 | EMail: Kurt.Zeilenga@Isode.COM 212 | 213 | 214 | 215 | 216 | 217 | 218 | 219 | 220 | Zeilenga Standards Track [Page 4] 221 | 222 | RFC 5020 LDAP entryDN August 2007 223 | 224 | 225 | Full Copyright Statement 226 | 227 | Copyright (C) The IETF Trust (2007). 228 | 229 | This document is subject to the rights, licenses and restrictions 230 | contained in BCP 78, and except as set forth therein, the authors 231 | retain all their rights. 232 | 233 | This document and the information contained herein are provided on an 234 | "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 235 | OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 236 | THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 237 | OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 238 | THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 239 | WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 240 | 241 | Intellectual Property 242 | 243 | The IETF takes no position regarding the validity or scope of any 244 | Intellectual Property Rights or other rights that might be claimed to 245 | pertain to the implementation or use of the technology described in 246 | this document or the extent to which any license under such rights 247 | might or might not be available; nor does it represent that it has 248 | made any independent effort to identify any such rights. Information 249 | on the procedures with respect to rights in RFC documents can be 250 | found in BCP 78 and BCP 79. 251 | 252 | Copies of IPR disclosures made to the IETF Secretariat and any 253 | assurances of licenses to be made available, or the result of an 254 | attempt made to obtain a general license or permission for the use of 255 | such proprietary rights by implementers or users of this 256 | specification can be obtained from the IETF on-line IPR repository at 257 | http://www.ietf.org/ipr. 258 | 259 | The IETF invites any interested party to bring to its attention any 260 | copyrights, patents or patent applications, or other proprietary 261 | rights that may cover technology that may be required to implement 262 | this standard. Please address the information to the IETF at 263 | ietf-ipr@ietf.org. 264 | 265 | Acknowledgement 266 | 267 | Funding for the RFC Editor function is currently provided by the 268 | Internet Society. 269 | 270 | 271 | 272 | 273 | 274 | 275 | 276 | Zeilenga Standards Track [Page 5] 277 | -------------------------------------------------------------------------------- /docs/rfc/other/errata/rfc2119-errata.txt: -------------------------------------------------------------------------------- 1 | 2 | Status: Verified (7) 3 | RFC2119, "Key words for use in RFCs to Indicate Requirement Levels", March 1997 4 | Source of RFC: Legacy 5 | Area Assignment: gen 6 | 7 | Errata ID: 493 8 | 9 | Status: Verified 10 | Type: Technical 11 | 12 | Reported By: Davidson, Malcolm 13 | Date Reported: 2001-05-31 14 | 15 | Section 1 says: 16 | 17 | 2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the 18 | definition is an absolute prohibition of the specification. 19 | 20 | It should say: 21 | 22 | 2. MUST NOT This phrase, or the phrase "SHALL NOT", means that the 23 | definition is an absolute prohibition of the specification. 24 | 25 | Errata ID: 495 26 | 27 | Status: Verified 28 | Type: Technical 29 | 30 | Reported By: Davidson, Malcolm 31 | Date Reported: 2001-05-31 32 | 33 | Section 1 says: 34 | 35 | 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the 36 | definition is an absolute requirement of the specification. 37 | 38 | 39 | It should say: 40 | 41 | 1. MUST This word, or the terms "REQUIRED" or "SHALL", means that the 42 | definition is an absolute requirement of the specification. 43 | 44 | Notes: 45 | 46 | 47 | Errata ID: 496 48 | 49 | Status: Verified 50 | Type: Technical 51 | 52 | Reported By: Kurt Zeilenga 53 | Date Reported: 2001-01-31 54 | 55 | Section 6 says: 56 | 57 | In particular, they MUST only be used where it is actually required 58 | for interoperation or to limit behavior which has potential for 59 | causing harm (e.g., limiting retransmisssions) For example, they 60 | must not be used to try to impose a particular method on 61 | implementors where the method is not required for interoperability. 62 | 63 | It should say: 64 | 65 | In particular, they MUST only be used where it is actually required 66 | for interoperation or to limit behavior which has potential for 67 | causing harm (e.g., limiting retransmissions). For example, they 68 | must not be used to try to impose a particular method on 69 | implementors where the method is not required for interoperability. 70 | 71 | Errata ID: 498 72 | 73 | Status: Verified 74 | Type: Technical 75 | 76 | Reported By: Davidson, Malcolm 77 | Date Reported: 2001-05-31 78 | 79 | Section 1 says: 80 | 81 | 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that 82 | there may exist valid reasons in particular circumstances when the 83 | particular behavior is acceptable or even useful, but the full 84 | implications should be understood and the case carefully weighed 85 | before implementing any behavior described with this label. 86 | 87 | It should say: 88 | 89 | 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED", means that 90 | there may exist valid reasons in particular circumstances when the 91 | particular behavior is acceptable or even useful, but the full 92 | implications should be understood and the case carefully weighed 93 | before implementing any behavior described with this label. 94 | 95 | Errata ID: 500 96 | 97 | Status: Verified 98 | Type: Technical 99 | 100 | Reported By: Davidson, Malcolm 101 | Date Reported: 2001-05-31 102 | 103 | Section 1 says: 104 | 105 | 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there 106 | may exist valid reasons in particular circumstances to ignore a 107 | particular item, but the full implications must be understood and 108 | carefully weighed before choosing a different course. 109 | 110 | It should say: 111 | 112 | 3. SHOULD This word, or the adjective "RECOMMENDED", means that there 113 | may exist valid reasons in particular circumstances to ignore a 114 | particular item, but the full implications must be understood and 115 | carefully weighed before choosing a different course. 116 | 117 | Errata ID: 494 118 | 119 | Status: Verified 120 | Type: Editorial 121 | 122 | Reported By: Davidson, Malcolm 123 | Date Reported: 2001-05-31 124 | Verifier Name: RFC Editor 125 | Date Verified: 2007-11-07 126 | 127 | Section 6 says: 128 | 129 | (e.g., limiting retransmisssions) 130 | 131 | It should say: 132 | 133 | (e.g., limiting retransmissions) 134 | 135 | Errata ID: 499 136 | 137 | Status: Verified 138 | Type: Editorial 139 | 140 | Reported By: Anders Langmyr 141 | Date Reported: 2006-01-09 142 | Verifier Name: Peter Saint-Andre 143 | Date Verified: 2011-11-15 144 | 145 | Section Abstract says: 146 | 147 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 148 | NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 149 | "OPTIONAL" in this document are to be interpreted as described in 150 | RFC 2119. 151 | 152 | It should say: 153 | 154 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 155 | NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 156 | RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 157 | be interpreted as described in RFC 2119. 158 | 159 | Notes: 160 | 161 | The phrase "NOT RECOMMENDED" is missing from this sentence. 162 | Status: Held for Document Update (1) 163 | RFC2119, "Key words for use in RFCs to Indicate Requirement Levels", March 1997 164 | Source of RFC: Legacy 165 | Area Assignment: gen 166 | 167 | Errata ID: 2969 168 | 169 | Status: Held for Document Update 170 | Type: Technical 171 | 172 | Reported By: John Klensin 173 | Date Reported: 2011-09-12 174 | Held for Document Update by: Russ Housley 175 | 176 | Section 1,3,4 says: 177 | 178 | (1) "The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" mean 179 | 180 | (2) 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean 181 | 182 | (3) 3. SHOULD This word, or the adjective "RECOMMENDED", mean 183 | 184 | (4) 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean 185 | 186 | It should say: 187 | 188 | (1) "The key words "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", and "MAY" means 189 | 190 | (2) 1. MUST This word, or the term "SHALL", means 191 | 192 | (3) 3. SHOULD This word means 193 | 194 | (4) 4. SHOULD NOT This phrase means 195 | 196 | Editorial note: The use of "mean" after a singular subject is simply wrong. Subordinate phrases like ", or the term BLATHER," do nothing to change that. 197 | 198 | 199 | 200 | 201 | Notes: 202 | 203 | RFC 2026, to which RFC 2119 should be subordinate, carefully distinguishes between Technical Specifications (TS) and Applicability Statements (AS). Its Section 3.3 prescribes specific language to be used in ASs, with categories "Required", "Recommended", "Elective", "Limited Use", and "Not Recommended", while 2119's language, especially in its Section 6, fairly clearly apply to interoperability requirements within TS documents. Use of terms that 2026 requires for AS documents in a TS context (as synonyms for other, unambiguous, terms) is just an invitation to confusion, especially if the IETF continues to have hair-splitting arguments about the nature of requirements in particular contexts. Consequently, while the change proposed in erratum 419 (altering the definition phrase to reflect the language of Section 4) appears reasonable from an editorial standpoint, the correct fix is to remove the 2026 AS terms as acceptable synonyms from 2119 entirely. If people want to say "SHOULD NOT" and give it specific meaning, they should say "SHOULD NOT" rather than trying to use nearly-synonymous terms and hoping that the reader will figure out what was really met. 204 | Status: Rejected (1) 205 | RFC2119, "Key words for use in RFCs to Indicate Requirement Levels", March 1997 206 | Source of RFC: Legacy 207 | Area Assignment: gen 208 | 209 | Errata ID: 497 210 | 211 | Status: Rejected 212 | Type: Editorial 213 | 214 | Reported By: Kiyoshi Ogawa 215 | Date Reported: 2006-07-10 216 | Rejected by: Russ Housley 217 | Date Rejected: 2010-08-19 218 | 219 | 220 | 221 | 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there 222 | may exist valid reasons in particular circumstances to ignore a 223 | particular item, but the full implications must be understood and 224 | carefully weighed before choosing a different course. 225 | 226 | 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that 227 | there may exist valid reasons in particular circumstances when the 228 | particular behavior is acceptable or even useful, but the full 229 | implications should be understood and the case carefully weighed 230 | before implementing any behavior described with this label. 231 | 232 | It should say: 233 | 234 | 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there 235 | may exist valid reasons in particular circumstances to ignore a 236 | particular item, but the full implications should be understood and 237 | carefully weighed before choosing a different course. 238 | 239 | 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that 240 | there may exist valid reasons in particular circumstances when the 241 | particular behavior is acceptable or even useful, but the full 242 | implications should be understood and the case carefully weighed 243 | before implementing any behavior described with this label. 244 | 245 | Notes: 246 | 247 | OR should say: 248 | 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there 249 | may exist valid reasons in particular circumstances to ignore a 250 | particular item, but the full implications is understood and 251 | carefully weighed before choosing a different course. 252 | 253 | 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that 254 | there may exist valid reasons in particular circumstances when the 255 | particular behavior is acceptable or even useful, but the full 256 | implications should be understood and the case carefully weighed 257 | before implementing any behavior described with this label. 258 | 259 | 260 | The change request is "must" to "should". 261 | It may be self definition. 262 | For the balance of SHOULD and SHOULD NOT , it should use "should", not 263 | "must". 264 | --VERIFIER NOTES-- 265 | The full implications MUST be understood in order to ignore a "SHOULD" or "SHOULD NOT" statement in a specification. -------------------------------------------------------------------------------- /docs/rfc/other/errata/rfc2849-errata.txt: -------------------------------------------------------------------------------- 1 | RFC2849, "The LDAP Data Interchange Format (LDIF) - Technical Specification", June 2000 2 | Source of RFC: IETF - NON WORKING GROUP 3 | Area Assignment: app 4 | 5 | Errata ID: 2258 6 | 7 | Status: Held for Document Update 8 | Type: Technical 9 | 10 | Reported By: Flavio Poletti 11 | Date Reported: 2010-05-13 12 | Held for Document Update by: Peter Saint-Andre 13 | 14 | Throughout the document, when it says: 15 | 16 | Example 3: A file containing a base-64-encoded value 17 | 18 | version: 1 19 | dn: cn=Gern Jensen, ou=Product Testing, dc=airius, dc=com 20 | objectclass: top 21 | objectclass: person 22 | objectclass: organizationalPerson 23 | cn: Gern Jensen 24 | cn: Gern O Jensen 25 | sn: Jensen 26 | uid: gernj 27 | telephonenumber: +1 408 555 1212 28 | description:: V2hhdCBhIGNhcmVmdWwgcmVhZGVyIHlvdSBhcmUhICBUaGlzIHZhbHVl 29 | IGlzIGJhc2UtNjQtZW5jb2RlZCBiZWNhdXNlIGl0IGhhcyBhIGNvbnRyb2wgY2hhcmFjdG 30 | VyIGluIGl0IChhIENSKS4NICBCeSB0aGUgd2F5LCB5b3Ugc2hvdWxkIHJlYWxseSBnZXQg 31 | b3V0IG1vcmUu 32 | 33 | It should say: 34 | 35 | Example 3: A file containing a base-64-encoded value 36 | 37 | version: 1 38 | dn: cn=Gern Jensen, ou=Product Testing, dc=airius, dc=com 39 | objectclass: top 40 | objectclass: person 41 | objectclass: organizationalPerson 42 | cn: Gern Jensen 43 | cn: Gern O Jensen 44 | sn: Jensen 45 | uid: gernj 46 | telephonenumber: +1 408 555 1212 47 | description:: V2hhdCBhIGNhcmVmdWwgcmVhZGVyIHlvdSBhcmUhICBUaGlzIHZhbHVl 48 | IGlzIGJhc2UtNjQtZW5jb2RlZCBiZWNhdXNlIGl0IGhhcyBhIGNvbnRyb2wgY2hhcmFjdG 49 | VyIGluIGl0IChhIENSKS4NICBCeSB0aGUgd2F5LCB5b3Ugc2hvdWxkIHJlYWxseSBnZXQg 50 | b3V0IG1vcmUu 51 | 52 | Notes: 53 | 54 | There is no section numbering in this RFC, hence the "GLOBAL". 55 | 56 | Note 10 in "Notes on LDIF Syntax" says that base64-encoded values are subject to the same folding rules explained in Note 2. Note 2 requires folded lines to begin with a space character. 57 | 58 | This modification was introduced passing from draft-good-ldap-ldif to RFC 2849. 59 | 60 | Errata ID: 3646 61 | 62 | Status: Held for Document Update 63 | Type: Editorial 64 | 65 | Reported By: Boris Kleint 66 | Date Reported: 2013-06-11 67 | Held for Document Update by: Barry Leiba 68 | Date Held: 2013-08-21 69 | 70 | Section Note 4 says: 71 | 72 | Any dn or rdn that contains characters other than those 73 | defined as "SAFE-UTF8-CHAR", or begins with a character other 74 | than those defined as "SAFE-INIT-UTF8-CHAR", 75 | 76 | It should say: 77 | 78 | Any dn or rdn that contains characters other than those 79 | defined as "SAFE-CHAR", or begins with a character other 80 | than those defined as "SAFE-INIT-CHAR", 81 | 82 | Notes: 83 | 84 | This appears in note 4 of "Notes on LDIF Syntax". 85 | 86 | ---- Verifier notes ---- 87 | Note 4 has double text, one of which allows more than the other. But the ABNF 88 | doesn't have that ambiguity. This is really something that can only be fixed by 89 | revising the spec. It's simply not clear what the intent was. -------------------------------------------------------------------------------- /docs/rfc/other/errata/rfc3454-errata.txt: -------------------------------------------------------------------------------- 1 | Status: Verified (1) 2 | RFC3454, "Preparation of Internationalized Strings ("stringprep")", December 2002 3 | Source of RFC: IETF - NON WORKING GROUP 4 | 5 | Errata ID: 806 6 | 7 | Status: Verified 8 | Type: Technical 9 | 10 | Reported By: Sergiusz Wolicki 11 | Date Reported: 2006-04-27 12 | 13 | Section Appendix C says: 14 | 15 | C. Prohibition tables 16 | 17 | The tables in this appendix consist of lines with one prohibited code 18 | point per line. The format of the lines are the value of the code 19 | point, a semicolon, and a comment which is the name of the code 20 | point. 21 | 22 | It should say: 23 | 24 | [see Notes] 25 | 26 | Notes: 27 | 28 | This is not true as the tables in this appendix consist of lines with 29 | one prohibited code point _range_ per line. The format of the lines 30 | are the value of the starting code point of the range, a hyphen, 31 | the value of the ending code point of the range, a semicolon, 32 | and a comment which is the informal name of the range in square brackets. 33 | If the range contains only one code point, then the hyphen and the ending 34 | code point value are omitted, and the comment contains the name of 35 | the code point without brackets. 36 | 37 | from pending 38 | Status: Held for Document Update (1) 39 | RFC3454, "Preparation of Internationalized Strings ("stringprep")", December 2002 40 | Source of RFC: IETF - NON WORKING GROUP 41 | 42 | Errata ID: 2686 43 | 44 | Status: Held for Document Update 45 | Type: Editorial 46 | 47 | Reported By: Jehan Pagès 48 | Date Reported: 2011-01-20 49 | Held for Document Update by: Alexey Melnikov 50 | 51 | Section 3.2 says: 52 | 53 | The list of characters to add to the mapping table can determined by the following algorithm: 54 | 55 | It should say: 56 | 57 | The list of characters to add to the mapping table can be determined by the following algorithm: 58 | 59 | Notes: 60 | 61 | A small omission of a single word: "be" is missing. -------------------------------------------------------------------------------- /docs/rfc/other/errata/rfc4122-errata.txt: -------------------------------------------------------------------------------- 1 | Status: Verified (5) 2 | RFC4122, "A Universally Unique IDentifier (UUID) URN Namespace", July 2005 3 | Source of RFC: IETF - NON WORKING GROUP 4 | Area Assignment: app 5 | 6 | Errata ID: 1352 7 | 8 | Status: Verified 9 | Type: Technical 10 | 11 | Reported By: Frank Ellermann 12 | Date Reported: 2008-03-08 13 | Verifier Name: Alexey Melnikov 14 | Date Verified: 2009-12-04 15 | 16 | In Appendix B, it says: 17 | 18 | uuid_create_md5_from_name(): e902893a-9d22-3c7e-a7b8-d6e313b71d9f 19 | 20 | It should say: 21 | 22 | uuid_create_md5_from_name(): 3d813cbb-47fb-32ba-91df-831e1593ac29 23 | 24 | Notes: 25 | 26 | The given value e902... etc. is based on a calculation swapping the eight octets 0..3, 4..5, 6..7 twice, for the name space UUID, and for the MD5 output, as foreseen for little endian input, but the example values were already big endian. I can reproduce the example and the proposed fix, see . 27 | 28 | The blog entry contains links to an identical older error report, and two (different) examples from third parties also agreeing with that theory. 29 | 30 | Errata ID: 1428 31 | 32 | Status: Verified 33 | Type: Technical 34 | 35 | Reported By: Russ Housley 36 | Date Reported: 2008-05-22 37 | Verifier Name: Alexey Melnikov 38 | Date Verified: 2009-12-04 39 | 40 | Section 3 says: 41 | 42 | UUIDs, as defined in this document, can also be ordered lexicographically. 43 | For a pair of UUIDs, the first one follows the second if the most significant 44 | field in which the UUIDs differ is greater for the first UUID. The second 45 | precedes the first if the most significant field in which the UUIDs differ 46 | is greater for the second UUID. 47 | 48 | It should say: 49 | 50 | UUIDs, as defined in this document, can also be ordered lexicographically. 51 | For a pair of UUIDs, the first one follows the second if the most significant 52 | field in which the UUIDs differ is greater for the first UUID. The second 53 | follows the first if the most significant field in which the UUIDs differ 54 | is greater for the second UUID. 55 | 56 | Notes: 57 | 58 | The second and third sentences in the paragraph as originally written are 59 | inconsistent. I have proposed one of the possible fixes. There are others 60 | that will make them consistent. 61 | 62 | Errata ID: 3641 63 | 64 | Status: Verified 65 | Type: Technical 66 | 67 | Reported By: Douglas Ray 68 | Date Reported: 2013-06-06 69 | Verifier Name: Barry Leiba 70 | Date Verified: 2013-06-06 71 | 72 | Throughout the document, when it says: 73 | 74 | Advice on generating cryptographic-quality random numbers can be 75 | found in RFC1750 [5]. 76 | 77 | It should say: 78 | 79 | Advice on generating cryptographic-quality random numbers can be 80 | found in RFC4086 [5]. 81 | 82 | Notes: 83 | 84 | (Above sample is from section 4.5). 85 | References to RFC 1750 should currently refer to RFC 4086. 86 | (Likewise in Appendix A.) 87 | The note [5] actually references RFC4086, but this is the only 88 | point that is updated, ie, the document is inconsistent in its references. 89 | The references in Appendix A are not cross-referenced to note [5]. 90 | 91 | ------------------------ Verifier notes ------------------------ 92 | This is correct: reference [5] was updated to point to 4086, but the text in the 93 | document body was not changed accordingly. 94 | 95 | Errata ID: 184 96 | 97 | Status: Verified 98 | Type: Editorial 99 | 100 | Reported By: Tim Wilson-Brown 101 | Date Reported: 2006-05-03 102 | Verifier Name: Alexey Melnikov 103 | Date Verified: 2009-12-04 104 | 105 | Section 4.3 says: 106 | 107 | The UUIDs generated from the same name in two different namespaces 108 | should be different with (very high probability). 109 | 110 | It should say: 111 | 112 | The UUIDs generated from the same name in two different namespaces 113 | should be different (with very high probability). 114 | 115 | Notes: 116 | 117 | The brackets should be set similarly to the other points. 118 | 119 | Errata ID: 3476 120 | 121 | Status: Verified 122 | Type: Editorial 123 | 124 | Reported By: Simon Kissane 125 | Date Reported: 2013-02-02 126 | Verifier Name: Barry Leiba 127 | Date Verified: 2013-02-03 128 | 129 | Section Appendix A,B says: 130 | 131 | In Appendix A, the line: 132 | uuid_create_md5_from_name(&u, NameSpace_DNS, "www.widgets.com", 15); 133 | In Appendix B, the line: 134 | uuid_create_md5_from_name(): e902893a-9d22-3c7e-a7b8-d6e313b71d9f 135 | 136 | It should say: 137 | 138 | In Appendix A, the line: 139 | uuid_create_md5_from_name(&u, NameSpace_DNS, "www.example.com", 15); 140 | In Appendix B, the line: 141 | uuid_create_md5_from_name(): 5df41881-3aed-3515-88a7-2f4a814cf09e 142 | 143 | Notes: 144 | 145 | Per RFC2606 section 5, it is best practice for standards and other documentation (including RFCs) to use the reserved example domains (e.g. example.com) rather than domains which could be in actual use. Indeed, the domain in question (www.widgets.com) is in actual use at the time of writing. So this proposed change uses "www.example.com" instead, and changes the example output accordingly. (Note that original output was wrong for the original input, as already noted in verified errata 1352.) 146 | Status: Held for Document Update (2) 147 | RFC4122, "A Universally Unique IDentifier (UUID) URN Namespace", July 2005 148 | Source of RFC: IETF - NON WORKING GROUP 149 | Area Assignment: app 150 | 151 | Errata ID: 3546 152 | 153 | Status: Held for Document Update 154 | Type: Technical 155 | 156 | Reported By: Askar Safin 157 | Date Reported: 2013-03-14 158 | Held for Document Update by: Barry Leiba 159 | Date Held: 2013-03-20 160 | 161 | Section 4.1.3 says: 162 | 163 | The version number is in the most significant 4 bits of the time 164 | stamp (bits 4 through 7 of the time_hi_and_version field). 165 | 166 | It should say: 167 | 168 | The version number is in the most significant 4 bits of the time 169 | stamp (bits 0 through 3 of the time_hi_and_version field). 170 | 171 | Notes: 172 | 173 | We use network order (as far as I know, we use network order in this RFC both for bits and bytes). So, the most significant bits comes first and they are located in first bytes. So, 0 through 3. 174 | 175 | ---VERIFIER NOTES --- 176 | This erratum is correct as far as it goes, but, given other text in the RFC, so is erratum 1957. There is a pervasive problem in this RFC with inconsistent and unclear usage of bit numbering, which switches between several conventions. The diagram in Section 4.1.2 uses left-to-right bit numbering (the most significant bit is numbered 0), but much of the text (such as in Section 4.2.2) uses right-to-left bit numbering (the least significant bit is numbered 0). Most of the text uses big-ending byte order (network byte order), but some seems to assume little-ending, probably mistakes that come from the authors' familiarity with that convention. 177 | 178 | With respect to the text in question, the first sentence of Section 4.1.3, we have the following situation: 179 | 180 | - The original text is correct if we assume right-to-left bit numbering and little-endian byte order. 181 | 182 | - Erratum 1957 is correct if we assume right-to-left bit numbering and big-endian byte order. This change also makes the first sentence of Section 4.1.3 consistent with the sixth bullet in Section 4.2.2. 183 | 184 | - Erratum 3546 is correct if we assume left-to-right bit numbering and big-endian byte order. 185 | 186 | In the end, the real point is that this document needs a revision that carefully and thoroughly fixes every instance of byte numbering (or removes the byte numbering and refers only to "most significant" and "least significant"). Such a revision should also double-check the sample code in Appendix A to be sure it works in both big-ending and little-endian machines. 187 | 188 | Happily, it's not likely that misunderstandings here will cause actual interoperability problems: this isn't a situation where things need to be disassembled and reassembled. The algorithm merely turns a UUID into a URN, and the URN is thereafter a "black box", an unchanged identifier. The only issue would be whether different interpretations of the document would turn two different UUIDs into the same URN, and, given the number of bits involved, the likelihood of collisions in practice is small. 189 | 190 | Errata ID: 1957 191 | 192 | Status: Held for Document Update 193 | Type: Technical 194 | 195 | Reported By: Sergey Shandar 196 | Date Reported: 2009-12-03 197 | Held for Document Update by: Barry Leiba 198 | Date Held: 2013-03-20 199 | 200 | Section 4.1.3 says: 201 | 202 | The version number is in the most significant 4 bits of the time 203 | stamp (bits 4 through 7 of the time_hi_and_version field). 204 | 205 | It should say: 206 | 207 | The version number is in the most significant 4 bits of the time 208 | stamp (bits 12 through 15 of the time_hi_and_version field). 209 | 210 | Notes: 211 | 212 | time_hi_and_version is defined as 16 bit field. 213 | 214 | --- VERIFIER NOTES --- 215 | This change does make the text in Section 4.1.3 consistent with the sixth 216 | bullet in Section 4.2.2. But the issue goes well beyond that: there is a real 217 | problem with the bit numbering throughout the RFC. Please see erratum 218 | 3546 for more details. 219 | Status: Rejected (1) 220 | RFC4122, "A Universally Unique IDentifier (UUID) URN Namespace", July 2005 221 | Source of RFC: IETF - NON WORKING GROUP 222 | Area Assignment: app 223 | 224 | Errata ID: 3970 225 | 226 | Status: Rejected 227 | Type: Technical 228 | 229 | Reported By: Jennifer Arsenault 230 | Date Reported: 2014-04-19 231 | Rejected by: Barry Leiba 232 | Date Rejected: 2014-05-07 233 | 234 | Section 4.1.3 says: 235 | 236 | The version number is in the most significant 4 bits of the time 237 | stamp (bits 4 through 7 of the time_hi_and_version field). 238 | 239 | It should say: 240 | 241 | The version number is in the most significant 4 bits of the 242 | time_hi_and_version field... 243 | 244 | Notes: 245 | 246 | Errata 1957 and 3546 refer to the inconsistent bit numbering. That is a separate issue and has been left out of this correction. This report is in reference to the use of "time stamp" vs "time_hi_and_version field". The version number does not replace the most significant 4 bits of the time stamp. The 4-bit version number is in addition to the 60-bit time stamp. 247 | --VERIFIER NOTES-- 248 | This seems to be a misunderstanding of the meaning here: 249 | The time_hi_and_version field includes 4 bits for version, followed by the most significant 12 bits of the time stamp. Therefore, the most significant four bits of the time stamp *are* bits 4 thru 7 of the time_hi_and_version field. 250 | 251 | That said, this is all a confusing mess, and really could use a revision for clarity. 252 | -------------------------------------------------------------------------------- /docs/rfc/other/errata/rfc4234-errata.txt: -------------------------------------------------------------------------------- 1 | Status: Verified (1) 2 | RFC4234, "Augmented BNF for Syntax Specifications: ABNF", October 2005 3 | 4 | Note: This RFC has been obsoleted by RFC5234 5 | Source of RFC: IETF - NON WORKING GROUP 6 | Area Assignment: app 7 | 8 | Errata ID: 160 9 | 10 | Status: Verified 11 | Type: Technical 12 | 13 | Reported By: Alfred Hoenes 14 | Date Reported: 2005-10-13 15 | 16 | Section 3.10 says: 17 | 18 | Strings, Names formation 19 | 20 | Comment 21 | 22 | Value range 23 | 24 | Repetition 25 | 26 | Grouping, Optional 27 | 28 | Concatenation 29 | 30 | Alternative 31 | 32 | It should say: 33 | 34 | Strings, Names formation 35 | 36 | Comment 37 | 38 | Value range 39 | 40 | Grouping, Optional 41 | 42 | Repetition 43 | 44 | Concatenation 45 | 46 | Alternative 47 | 48 | 49 | Notes: 50 | 51 | This re-ordering aligns the table with the prose description and the 52 | meta-grammar in section 4. 53 | Status: Held for Document Update (1) 54 | RFC4234, "Augmented BNF for Syntax Specifications: ABNF", October 2005 55 | 56 | Note: This RFC has been obsoleted by RFC5234 57 | Source of RFC: IETF - NON WORKING GROUP 58 | Area Assignment: app 59 | 60 | Errata ID: 2625 61 | 62 | Status: Held for Document Update 63 | Type: Editorial 64 | 65 | Reported By: Alfred Hoenes 66 | Date Reported: 2005-10-13 67 | Held for Document Update by: Pete Resnick 68 | Date Held: 2010-11-12 69 | 70 | Section Appendix B.2 says: 71 | 72 | Externally, data are represented as "network virtual ASCII" (namely, 73 | 7-bit US-ASCII in an 8-bit field), with the high (8th) bit set to 74 | zero. 75 | 76 | It should say: 77 | 78 | Externally, data are represented as "network virtual ASCII" (namely, 79 | 7-bit US-ASCII in an 8-bit field, with the high (8th) bit set to 80 | zero). 81 | 82 | Notes: 83 | 84 | This change should make it clear (as in RFC 2234) that the phrase, 85 | "with the high (8th) bit set to zero" is an intrinsic part of the 86 | full definition of "network virtual ASCII", and not the specification 87 | of an exception -- or an additional manipulation for the purpose of 88 | ABNF -- to "network virtual ASCII". 89 | Status: Rejected (5) 90 | RFC4234, "Augmented BNF for Syntax Specifications: ABNF", October 2005 91 | 92 | Note: This RFC has been obsoleted by RFC5234 93 | Source of RFC: IETF - NON WORKING GROUP 94 | Area Assignment: app 95 | 96 | Errata ID: 777 97 | 98 | Status: Rejected 99 | Type: Technical 100 | 101 | Reported By: Zoltan Ordogh 102 | Date Reported: 2006-09-18 103 | Rejected by: Alexey Melnikov 104 | Date Rejected: 2010-09-02 105 | 106 | Section 3.4 says: 107 | 108 | A range of alternative numeric values can be specified compactly, 109 | using dash ("-") to indicate the range of alternative values. Hence: 110 | 111 | DIGIT = %x30-39 112 | 113 | is equivalent to: 114 | 115 | DIGIT = "0" / "1" / "2" / "3" / "4" / "5" / "6" / 116 | 117 | "7" / "8" / "9" 118 | 119 | It should say: 120 | 121 | [not supplied] 122 | 123 | Notes: 124 | 125 | The word equivalent is correct only when US-ASCII character set is used, since: 126 | 127 | DIGIT = %x30-39 ; 128 | means any hexadecimal value between 0x30 and 0x39, 129 | 130 | while 131 | 132 | DIGIT = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" ; 133 | means any digit from 0 thru 9. 134 | 135 | from pending 136 | --VERIFIER NOTES-- 137 | As per Note in Section 2.3: 138 | 139 | ABNF strings are case-insensitive and the character set for these 140 | strings is us-ascii. 141 | 142 | So these 2 representations *are* equivalent. 143 | 144 | Errata ID: 778 145 | 146 | Status: Rejected 147 | Type: Technical 148 | 149 | Reported By: Zoltan Ordogh 150 | Date Reported: 2006-09-18 151 | Rejected by: Alexey Melnikov 152 | Date Rejected: 2010-09-02 153 | 154 | In Appendix B.1, it says: 155 | 156 | CHAR = %x01-7F 157 | ; any 7-bit US-ASCII character, 158 | ; excluding NUL 159 | 160 | It should say: 161 | 162 | [see below] 163 | 164 | Notes: 165 | 166 | NUL is not defined. 167 | 168 | Suggestions: 169 | (1) 170 | Re-write the document in a character-encoding-independent manner. 171 | (2) 172 | Add definition of NUL (or NULL) as terminating null character - watch = 173 | out for character encoding! 174 | (3) 175 | Add definition of NOTNULL as any character but terminating null = 176 | character - watch out for character encoding! 177 | 178 | from pending 179 | --VERIFIER NOTES-- 180 | NUL is defined in US-ASCII. 181 | 182 | Errata ID: 783 183 | 184 | Status: Rejected 185 | Type: Technical 186 | 187 | Reported By: Alfred Hoenes 188 | Date Reported: 2005-10-13 189 | Rejected by: Peter Saint-Andre 190 | Date Rejected: 2010-11-18 191 | 192 | 193 | 194 | The following clarifications apply to the meta-grammar in section 4. 195 | 196 | a) Near the bottom of page 10, the rule: 197 | 198 | repetition = [repeat] element 199 | 200 | should say: 201 | 202 | | repetition = ( [repeat] element ) / option 203 | 204 | At the top of page 11, the rule: 205 | 206 | element = rulename / group / option / 207 | char-val / num-val / prose-val 208 | 209 | should say: 210 | 211 | | element = rulename / group / 212 | char-val / num-val / prose-val 213 | 214 | These changes have the effect to formally disallow 215 | a element in front of an