[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: schema-07 comments
At 01:37 PM 6/2/2004, Kathy Dally wrote:
>Thanks for your input. My responses (kld:) are
>in-line below. One general remark. The line
>wrapping problems were not in my original. I'll
>take this up with the RFC Editor.
I note that the RFC Editor is not involved in I-D
publication process. I-D publication is handled
by the Secretariat.
It's my general experience that such problems
are more commonly a problem with the submission
than any action taken by the Secretariat. In most
cases, the I-D is published as submitted. Hence,
I suggest you double check what you submitted
using known good text readers. Here, text
readers (such as web browsers) are better than
text editors.
This I-D uses old templates. Please update to latest
Status of Memo text, latest IPR text, and latest
Copyright text. I note that a new ID checklist has
been published (replacing the old ID nits). Please
check these off:
http://www.ietf.org/ID-Checklist.html
The last item likely applies to most all LDAPBIS I-Ds.
I ask all Editors to address these new publication
requirements in the next I-D revisions. (I will
provide examples in the form of updates to I-Ds
I'm editing shortly.)
Kurt
>Regards,
>Kathy Dally
>
>
>-----Original Message-----
>From: owner-ietf-ldapbis@OpenLDAP.org
>[mailto:owner-ietf-ldapbis@OpenLDAP.org] On Behalf
>Of Hallvard B Furuseth
>Sent: Wednesday, June 02, 2004 11:49 AM
>To: ietf-ldapbis@OpenLDAP.org
>Subject: schema-07 comments
>
>
>Mostly an update of my message 'schema comments'
>of 11. Dec 2003, which
>you seem to have missed.
>
>> 2.23 postalAddress
>> 2.27 registeredAddress
>
>> "15 Main St., Ottawa, Canada"
>
>Please use the LDAP syntax, "15 Main
>St.$Ottawa$Canada".
>kld: No. The example is a single address.
>Escaping the ","s is fixed.
>
>> 2.26 preferredDeliveryMethod
>
>> if mhs-delivery is preferred over
>telephone-delivery, which is
>> preferred over all other methods, the value of
>the value would
>> be {1, 9}.
>
>That's the ASN.1 representation. Please use the
>LDAP string syntax,
>"mhs $ telephone". Or spell your examples of DNs
>something like
>{{{"c", "US"}}, {{"o", "Something, Inc."}}}:-)
>kld: fixed
>
>> 2.43 x500UniqueIdentifier
>
>> In X.520 [X.520], this attribute type is
>called
>> uniqueIdentifier. This is a different
>attribute type from both the
>> "uid" and "uniqueIdentifier" attribute types.
> ^^^^^^^^^^^^^^^^
>If you mean an LDAP "uniqueIdentifier" attribute
>type, that is not
>defined in this document. Where is it defined?
>kld: It is in RFC 1274. However, we are trying
>to avoid references to that
> RFC. If "(uniqueIdentifier is specified in
>RFC 1274.)", was added
> to the paragraph would that be ok? Would
>RFC 1274 have to be included
> as an Informative Reference? Also, see 2.39
>in the I-D.
>--------------------------------------------------
>----------------------
>
>Editorial comments:
>
>Sections 2.21 (owner), 2.28 (roleOccupant):
>
><o=Widget',' Inc.> in DNs should be <o=Widget\,
>Inc.> or <o=Widget\2C
>Inc.'>. The -06 draft had a different error: The
>comma was unquoted.
>kld: fixed
>
>roleOccupant has lost 'o=' in front of Widget.
>kld: fixed
>
>2.30 (seeAlso), OTOH, has no comma in 'Widget
>Inc.'.
>
>2.40 (uniqueMember).
>
>I don't think DN examples should have space after
>the ',' between RDN
>components. IIRC, that was an LDAPv2ism.
>kld: fixed; Also, the bit string was moved to
>the end of the distinguished name.
>
>Also, these paragraphs have some bad formatting:
>Text dropped to the
>left with no margin, maybe after a spurious line
>break. Maybe the RFC
>Editor has another nroff than you. I've seen a
>similar effect when a
>nroff macro receives more arguments than it
>supported. For some nroff
>commands I believe it can be fixed by putting the
>.command alone on one
>line, so it will take the next line as its
>argument.
>
>Sections 1.4, 2.26, 2.30 and 2.40 have the same
>formatting problem.
>
>Spurious blank lines:
> Section 2.4: 2 in first paragraph.
> 2.9: 1 in last paragraph.
> 2.28: 1 in first paragraph.
> 2.42: 1 in first paragraph.
> 6: 1 in third paragraph.
> 7.2: 2 before the [LDAP-CRL] reference.
> Appendix A: 2 before item 2.
>kld: fixed
>
>Section 2.35 lacks a blank line before the
>attribute
>definition and has an extra blank line after it.
>kld: fixed
>
>These formatting problems seem to be new since
>schema-06, though I've
>only checked -06 for a few of them.
>
>> 1.1 Situation
>
>> Section 3.4 of
>> this document supercedes the technical
>specification for the 'dc'
>kld: not in my original
>
>Section 2.4.
>
>> 2.10 facsimileTelephoneNumber
>
>> numbers (and, optionally, the parameters) for
>facsimile terrminals.
>
>^^^^^^^^^^
>
>terminals.
>kld: fixed
>
>> 2.28 roleOccupant
>
>> objects(normally people) that fulfill the
>responsibilities of a role
> ^^^
> missing space
>kld: fixed
>
>> 2.32 sn
>
>> The sn (surname)attribute type contains name
>strings for the family
> ^^^
> missing space
>kld: fixed
>
>> 2.35 telephoneNumber
>
>> (e.g., 1 234 567 8901) Each number is one
>value of this
>
>Suggest '+1 ...' instead of '1 ...'.
>kld: ok
>
>
>> 2.40 uniqueMember
>
>> Distinguished Names of the object include a
>value that distinguishs
>
>^^^^^^^^^^^^
>
>distinguishes
>kld: fixed
>
>> "ou=1st Battalion#'010101', o=Defense, c=US".
>
>
>Missing 'B' after bit string.
>kld: fixed
>
>> 3.9 organizationalRole
>
>> represents a job or function or position in an
>organization.
> ^^^^
> job, function or position
>kld: fixed
>
>> 4. IANA Considerations
>
>> Specification: RFC XXXX [editor's note:
>The RFC number will be
>> the one assigned to this document.
>
>Missing ']'.
>kld: fixed
>
>> 7.1 Normative
>
>> ...[ROADMAP] Zeilenga, K., "LDAP: Technical
>Specification Road Map",
>
>Kill the '...'.
>kld: I don't understand what's wrong.
>
>> 7.2 Informative
>
>> [F.1] Operational Provisions For The
>International Public Telegram
>> Service Transmission System, CCITT
>Recommmendation F.1, 1992
>
>Indent 2nd line.
>kld: fixed
>
>> Appendix A Changes RFC 2256
>
>s/Changes/Changes made since/.
>
>There are more changes:
>
>- Removed '{number}' (minimum lower bound?) after
>the SYNTAX oid for
> all attributes that had that.
>
>- Added text about Unicode, SASLprep and UTF-8 for
>userPassword.
>kld: ok
>
>--
>Hallvard