bcp64-04 notes

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

> 3.4. Object Identifier Descriptors

>    LDAP allows short descriptive names (or descriptors) to be used
>    instead of a numeric Object Identifier to identify select protocol
>    extensions [Protocol],

Which extensions?  The extension OIDs I know of are all LDAPOIDs, which
[Protocol] 4.1.2 (String Types) constrains to <numericoid>:
Control.controlType, ExtendedRequest.requestName,
ExtendedResponse.responseName and IntermediateResponse.responseName.

Also, prepend "most" here since the following does not apply to
syntaxes:

>    schema elements [Models], LDAP URL [LDAPURL]
>    extensions, and other objects.

> 3.6. LDAP Message Types
>
>    Each protocol message is encapsulated in an LDAPMessage envelope
>    [Protocol].  The protocolOp CHOICE indicates the type of message
>    encapsulated.  Each message type consists of an ASN.1 identifier in
>    the form of a keyword and a non-negative choice number.  The choice
>    number is combined with the class (APPLICATION) and data type
>    (CONSTRUCTED or PRIMITIVE) to construct the BER tag in the message's
>    encoding.

Someone who knows ASN.1 terminology must check me on this, but I have
the impression that the above is wrong:

- I believe the 'tag' only is the number or a conceptual entity
  including the combination of the class and the number, and that it is
  the 'identifier octets' which also include the CONSTRUCTED bit.
  (Yes, I know this is not how the LDAP C API uses 'tag').

- CONSTRUCTED/PRIMITIVE sounds like the 'encoding type' rather than
  the 'data type'.  I thought the data type was what is described by the
  tag.
  
- 'tag number' (if that's the right term), not 'choice number'.
  As far as an ASN.1 parser knows, an extensible CHOICE could allow two
  different choices [APPLICATION 3] and [3], right?

Similar comments apply to Section 3.10 (LDAP Filter Choice).

> 3.7. LDAP Authentication Method
>
>    The LDAP Bind operation supports multiple authentication methods
>    [Protocol].  Each authentication choice consists of an ASN.1
>    identifier in the form of a keyword and a non-negative integer.

This wording is rather strange.  To me it looks like it is saying that
both identifier and integer is sent over the protocol.  I assume it
refers to how it is written in the grammar.  The same applies to several
similar wordings in the document.

Also, you don't say how the integer is used.  I assume it is the
method's tag number in the CHOICE AuthenticationChoice, and that the
class is CONTEXT-SPECIFIC.

> 3.10. LDAP Filter Choice

>    The choice number is combined with the class (APPLICATION) and data

No, class CONTEXT-SPECIFIC.

>    New values will be registered upon Standards Action.

Why no reserved number spaces filter types for private use and for
experiments?

> 4. Registration Procedure
>
>
>    The procedure given here MUST be used by anyone who wishes to use a
>    new value of a type described in Section 3 of this document.

Except with Private Use identifiers.

Please prepend a brief sentence for would-be internet-draft authors who
do not yet know the internet-draft->RFC procedure, explaining at which
point the registration form should be submitted to IANA.  Does one
always first discusses the draft on some mailinglist?  Then submit it to
IESG, and maybe with a note to IESG that publication as RFC must wait?

>    Prior to submission of the Internet Draft (I-D) to the RFC Editor but
>    after IESG review and tentative approval, the document editor SHOULD
>    revise the I-D to use registered values.

s/document editor/document author/?

> 9. References
>
>    [[Note to the RFC Editor: please replace the citation tags used in
>    referencing Internet-Drafts with tags of the form RFCnnnn.]]

> A.6.  LDAP Message Type Registration Template
>    LDAP Message Name:
> A.7.  LDAP Authentication Method Registration Template
>    Authentication Method Name:
> A.8.  LDAP Result Code Registration Template
>    Result Code Name:
> A.8.  LDAP Search Scope Registration Template
>    Search Scope Name:
> A.9.  LDAP Filter Choice Registration Template
>    Filter Choice Name:
> A.10.  LDAP ModifyRequest Operation Registration Template
>    ModifyRequest Operation Name:

I would think one must register both name and number, and that both must
be unique in the registry.  (One must check both the name and the value
to see if a new spec conflicts with an old one.)

========================================================================

Editorial comments:

> 3.5. AttributeDescription Options

>    An option SHALL be restricted to a
>    string

     of

>    UTF-8 encoded Unicode characters limited by the following
>    ABNF:

> 3.9. LDAP Search Scope
>
>    LDAP SearchRequest messages carry a scope enumerated value to
>    indicate the extend of search within the DIT [Protocol] Each search

s/extend/extent/?  Missing period after [Protocol].

> 3.12. LDAP authzId Prefixes
>
>
>    Authorization Identities in LDAP are strings conforming to the
>    <authzId> production [AuthMeth].  This production is extensible.
>    Each new specific authorization form is identified by a prefix string
>    conforming to the following ABNF:
>
>
>         prefix = keystring COLON
>         COLON = %x3A ; COLON (":" U+003A)
>
>
>    Prefixes are case-insensitive.
>
>
>    While the protocol places no maximum length restriction upon option
>    strings, they should be short.  Options longer than 12 characters may
>    be viewed as too long to register.  (...)

s/option/prefix/ here and in the rest of the section.

-- 
Hallvard