[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: schema-07 comments

To: "Kathy Dally" <kdally@mitre.org>
Subject: RE: schema-07 comments
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Date: Wed, 02 Jun 2004 14:26:21 -0700
Cc: <ietf-ldapbis@OpenLDAP.org>
In-reply-to: <001601c448e1$74a8d680$47031d80@MITRE.ORG>
References: <HBF.20040602q4c4@bombur.uio.no> <001601c448e1$74a8d680$47031d80@MITRE.ORG>

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

Follow-Ups:
- I-D templates (was: schema-07 comments)
  - From: Hallvard B Furuseth <h.b.furuseth@usit.uio.no>

References:
- schema-07 comments
  - From: Hallvard B Furuseth <h.b.furuseth@usit.uio.no>
- RE: schema-07 comments
  - From: "Kathy Dally" <kdally@mitre.org>

Prev by Date: RE: schema-07 comments
Next by Date: RE: schema-07 comments
Index(es):
- Chronological
- Thread