Subject: schema-07 comments

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 2 Jun 2004 17:49:20 +0200

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".

> 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."}}}:-)

> 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?

------------------------------------------------------------------------

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.

roleOccupant has lost 'o=' in front of Widget.

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.

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.

Section 2.35 lacks a blank line before the attribute
definition and has an extra blank line after it.

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' 

Section 2.4.

> 2.10  facsimileTelephoneNumber

>   numbers (and, optionally, the parameters) for facsimile terrminals.  
                                                            ^^^^^^^^^^
                                                            terminals.

> 2.28  roleOccupant

>   objects(normally people) that fulfill the responsibilities of a role 
          ^^^
      missing space

> 2.32  sn

>    The sn (surname)attribute type contains name strings for the family 
                   ^^^
              missing space

> 2.35  telephoneNumber

>   (e.g., 1 234 567 8901)  Each number is one value of this 

Suggest '+1 ...' instead of '1 ...'.

> 2.40  uniqueMember

>    Distinguished Names of the object include a value that distinguishs 
                                                            ^^^^^^^^^^^^
                                                            distinguishes

>   "ou=1st Battalion#'010101', o=Defense, c=US".  

Missing 'B' after bit string.

> 3.9  organizationalRole

>   represents a job or function or position in an organization.
                    ^^^^
                 job,   function or position

> 4.  IANA Considerations

>      Specification: RFC XXXX [editor's note:  The RFC number will be 
>            the one assigned to this document.

Missing ']'.

> 7.1  Normative

> ...[ROADMAP]  Zeilenga, K., "LDAP:  Technical Specification Road Map",

Kill the '...'.

> 7.2  Informative

>    [F.1]  Operational Provisions For The International Public Telegram
>    Service Transmission System, CCITT Recommmendation F.1, 1992

Indent 2nd line.

> 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.

-- 
Hallvard

---

From: "Kathy Dally" <[email-masked]>
Date: Wed, 2 Jun 2004 16:37:42 -0400

Hi Hallvard!

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.

Regards,
Kathy Dally

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf
Of Hallvard B Furuseth
Sent: Wednesday, June 02, 2004 11:49 AM
To: [email-masked]
Subject: schema-07 comments

Mostly an update of my message 'schema comments'
of 11. Dec 2003, which
you seem to have missed.

> "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.

>   preferred over all other methods, the value of
the value would 

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

>   "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:

<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

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:
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.

>   this document supercedes the technical
specification for the 'dc' 
kld:  not in my original

Section 2.4.

 
^^^^^^^^^^
 
terminals.
kld:  fixed

>   objects(normally people) that fulfill the
responsibilities of a role 
          ^^^
      missing space
kld:  fixed

>    The sn (surname)attribute type contains name
strings for the family 
                   ^^^
              missing space
kld:  fixed

kld:  ok

 
^^^^^^^^^^^^
 
distinguishes
kld:  fixed

kld:  fixed

                    ^^^^
kld:  fixed

>            the one assigned to this document.

Missing ']'.
kld:  fixed

> ...[ROADMAP]  Zeilenga, K., "LDAP:  Technical
Specification Road Map",

Kill the '...'.
kld:  I don't understand what's wrong.

>    Service Transmission System, CCITT
Recommmendation F.1, 1992

Indent 2nd line.
kld:  fixed

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

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 2 Jun 2004 23:26:23 +0200

Kathy Dally writes:
>Hallvard B Furuseth:

> kld:  No.  The example is a single address.

Eh?  "$" doesn't separate different addresses, it is a separator
between lines of one address.  Look at the Postal Address examples
in [Syntaxes].

> Escaping the ","s is fixed.

What escaping?

> 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?

I have no idea.  How about:

  This is a different attribute type from both the "uid" and
  the obsolete "uniqueIdentifier" LDAP attribute types.
      ^^^^^^^^                    ^^^^

> Also, see 2.39 in the I-D.

OK:

>   The uid attribute type contains computer system login names
>   associated with the object.  (Source: RFC 1274,
>   RFC 2798).  Each name is one value of this multi-valued attribute.

Hm.  I wouldn't call RFC 2798 (inetOrgPerson) a source for uid, since
it's years newer than the use of uid in RFC 2253.  If you count RFCs
newer than uid as sources, isn't [Schema] itself just as good a source?

As far as I can tell, the source for uid is buried in RFC 2253 which
says that LDAP 'uid' = X.500 'userid', combined with RFC 1274 for
'userid'.

>>   this document supercedes the technical specification for the 'dc' 

Fixed after submission, then.  I've just verified that this sentence is
in the official -07 draft.

> kld:  I don't understand what's wrong.

The '...' in front of '[ROADMAP]' should be '   ', unless '...' has some
special meaning I don't know about.

>   all attributes that had that.

Whoops, I think I should have said 'minimum _upper_ bound'.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 02 Jun 2004 14:26:21 -0700

>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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 02 Jun 2004 15:53:45 -0700

I have a few comments to inject here...

At 02:26 PM 6/2/2004, Hallvard B Furuseth wrote:
>> that RFC.

s/references/normative references/

An informative reference would be okay.

>If "(uniqueIdentifier is specified in RFC 1274.)", was

uniqueIdentifier is not obsolete. RFC 1274 is still a proposed standard.

I suggest adding a statement to the existing text:
        The uniqueIdentifier attribute type is defined in [RFC1274].
and an informative reference.

>it's years newer than the use of uid in RFC 2253.

RFC 2798 provided an (informative) LDAP description for the uid attribute
type, whereas RFC 1274 provided an X.500 description of the attribute type.
This document supercedes both.

>If you count RFCs newer than uid as sources, isn't [Schema] itself just as good a source?

RFC 2798 specifically provided a previously missing LDAP
description.  RFC 2798 can be viewed as updating RFC 1274.

---

From: "Kathy Dally" <[email-masked]>
Date: Wed, 2 Jun 2004 19:07:27 -0400

Hi Hallvard!

As before, see "KLD2:".

Thanks,
Kathy Dally

-----Original Message-----
From: Hallvard B Furuseth
[mailto:[email-masked]] 
Sent: Wednesday, June 02, 2004 5:26 PM
To: Kathy Dally
Cc: [email-masked]
Subject: RE: schema-07 comments

> kld:  No.  The example is a single address.

Eh?  "$" doesn't separate different addresses, it
is a separator
between lines of one address.  Look at the Postal
Address examples
in [Syntaxes].

> Escaping the ","s is fixed.

What escaping?
KLD2:  Oops!  I wonder what I was looking at?
Fixed.

type, that is not
> kld: It is in RFC 1274.  However, we are trying
to avoid references to

  This is a different attribute type from both the
"uid" and
  the obsolete "uniqueIdentifier" LDAP attribute
types.
      ^^^^^^^^                    ^^^^

>   RFC 2798).  Each name is one value of this
multi-valued attribute.

Hm.  I wouldn't call RFC 2798 (inetOrgPerson) a
source for uid, since
it's years newer than the use of uid in RFC 2253.
If you count RFCs
newer than uid as sources, isn't [Schema] itself
just as good a source?
KLD2:  Yes, in a sense.  That's why uid is
included in [Schema].

As far as I can tell, the source for uid is buried
in RFC 2253 which
says that LDAP 'uid' = X.500 'userid', combined
with RFC 1274 for
'userid'.

KLD2:  The name 'uid' is introduced in RFC 2253
(and its successor -DN-xx), but it does not
specify the attribute type.  The 'userId'
attribute type is in RFC 1274 and does not exist
in X.500.  A definition of 'uid' in a more recent
specification style is given in RFC 2798.
[Schema]
replaces the informative definition of RFC 2798,
as stated in section 1.1.

>>   this document supercedes the technical
specification for the 'dc' 

Fixed after submission, then.  I've just verified
that this sentence is
in the official -07 draft.
KLD2:  Huh?  I thought you were referring to a
formatting problem.  I see that the section should
be "2.4".  Is there anything else?

> kld:  I don't understand what's wrong.

The '...' in front of '[ROADMAP]' should be '   ',
unless '...' has some
special meaning I don't know about.
KLD2:  Ahh!  I'm still learning the difference
between space and period!  Fixed.

>   all attributes that had that.

Whoops, I think I should have said 'minimum
_upper_ bound'.
KLD2:  Yes, caught it.

-- 
Hallvard

---

From: "Kathy Dally" <[email-masked]>
Date: Wed, 2 Jun 2004 19:11:55 -0400

Hi Kurt!

I agree with your wording and will include RFC
1274 as an Informative Reference.

Thanks,
Kathy

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]] 
Sent: Wednesday, June 02, 2004 6:54 PM
To: Hallvard B Furuseth
Cc: Kathy Dally; [email-masked]
Subject: RE: schema-07 comments

to avoid references to

types.

uniqueIdentifier is not obsolete. RFC 1274 is
still a proposed standard.

I suggest adding a statement to the existing text:
        The uniqueIdentifier attribute type is
defined in [RFC1274].
and an informative reference.

source for uid, since
>it's years newer than the use of uid in RFC 2253.

RFC 2798 provided an (informative) LDAP
description for the uid attribute
type, whereas RFC 1274 provided an X.500
description of the attribute type.
This document supercedes both.

>If you count RFCs newer than uid as sources,
isn't [Schema] itself just as good a source?
with RFC 1274 for
>'userid'.

RFC 2798 specifically provided a previously
missing LDAP
description.  RFC 2798 can be viewed as updating
RFC 1274.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 3 Jun 2004 08:13:23 +0200

> KLD2:  Huh?  I thought you were referring to a formatting problem.

Ah.  When I said "These formatting problems..." I meant "The above
formatting problems...".

> I see that the section should

No.

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 3 Jun 2004 11:15:50 +0200

>   http://www.ietf.org/ID-Checklist.html

1id-guidelines.txt still requires

         This document is an Internet-Draft and is subject to
         all provisions of Section 10 of RFC2026.

but the idnits-v1.31 program complains that this text should not be used
with the new templates.  It also refers to rfc2223bis-07, which has a
reference which looks buggy to RFC3667 section 5.2.  I've written to the
authors of the documents since I'm writing an I-D too, and will forward
the responses.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 03 Jun 2004 07:24:37 -0700

Hopefully this will be updated soon.  Talk is require
new text soon (e.g., refuse submissions which don't use
new text) .  So, please ignore this 1id-guidelines
statement regarding Section 10 of RFC 2026.  This section
is replaced by RFC 3667/3668.  See Section 5 and 6 of
RFC 3667 for notices for I-D.