At 08:43 PM 8/31/00 -0400, Scott Bradner wrote:
People seem to be focusing on the specifics of the case at hand
Right, let's look at another case.
RFC 1778 (Draft) "The String Representation of Standard (LDAPv2)
Attribute Syntaxes" and RFC 2252 (Proposed) "Lightweight Directory
Access Protocol (v3): Attribute Syntax Definitions" reference
RFC 1278 (Informational) "A string encoding of Presentation Address".
This Informational RFC is the normative specification of the
Presentation Address which these Standard Track LDAP
specifications reference.
RFC 1278, though initially targeted for the Standard Track,
the RFC was eventually approved as Informational. I believe
the minutes of IESG/IAB indicate that RFC 2026, 7.1 was not
meant to apply to RFC 1278.
I do not believe it was appropriate for RFC 1778 nor 2252 to have
referenced RFC 1278. Large portions of these LDAP syntax
specifications should have published as Informational for
the same reasons RFC 1278 was. Only those attribute syntaxes
which the underlying protocol (RFC 1777, RFC 2251) require
should have been defined on the Standard Track.
I hope that LDAPbis can fix during our (proposed) LDAPv3
revision effort.
Kurt
--- relevant IESG/IAB meeting minutes (excerpts) ---
IESG 91-08-29, 3.5.4 ``A string encoding of Presentation Address''
This document provides a string encoding of OSI presentation
addresses, which is appropriate for use in human interactions, for
humans to write on paper, and for human to machine interfacing. It is
important to recognize that the encoding specified here is not
intended for internal storage inside the directory system.
Ross Callon and the author Steve Hardcastle-Kille agreed that this
should be a standards track document. A long discussion ensued about
the appropriateness of standardizing user interfaces and presentation
formats. The IESG was generally of the belief that a human exchange
format like RFC 822 addresses was needed, but it was not clear whether
they should be explicit standards or just common practice. The
specification of a single "common" format gained significant support,
but no consensus was reached.
Other groups are beginning to standardize presentation formats,
including the Operational statistics group, which is working on
standard maps and standards reports.
No resolution was reached on the status of this document.
ACTION: Vaudreuil -- Schedule a discussion on the appropriateness of
standardizing presentation formats.
IESG 91-09-19, 2.11) String Encoding of Presentation Addresses
This recommendation was approved pending the insertion of text
supplied by Phill Gross. This text describes the IESG position on the
standardization of user interfaces. Further discussion is documented
later in these minutes.
Action: Vaudreuil -- Edit the recommendation to publish the String
Encoding of Presentation Addresses document as a proposed standard and
send to the IAB.
Phill Gross's text on the standardization of user interfaces was a
general purpose statement of IESG understanding. As such the
IESG encouraged Phill to expand on the text with the intention of
publication of this as an RFC.
ACTION: Gross -- Elaborate on the User Interface Policy statement with
the intention of publishing it as a RFC.
IESG 91-10-17, 2) IAB Meeting Report (excerpt)
Steve Hardcastle-Kille joined the IAB in discussing several of the
X.500 documents. All were approved per the IESG recommendation except the
"String Encoding of Presentation Address" which with the concurrence
of Steve Hardcastle-Kille was suggested as an informational document.
IAB, 911010, 5.2 Presentation Address Encoding
The IAB was concerned that this appeared to be standardizing a
user interface, and there were some strong feelings that as a
general policy, standardizing user interfaces is a bad idea.
Hardcastle-Kille agreed that this memo will have most of the
desired effect as an Informational RFC, so it was agreed to
publish it in this manner.